■ — -  Software  Engineering  Institute 


Guide  for  SCAMPI  Appraisals: 
Accelerated  Improvement  Method  (AIM) 


Gene  Miluk 
James  McHale 
Timothy  A.  Chick 


December  2010 

SPECIAL  REPORT 

CMU/SEI-201 0-SR-021 


Software  Engineering  Process  Management  (SEPM)  Program 

Unlimited  distribution  subject  to  the  copyright. 


http://www.sei.cmu.edu 


Carnegie  Mellon 


Report  Documentation  Page 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 


1.  REPORT  DATE 

DEC  2010 


2.  REPORT  TYPE 


3.  DATES  COVERED 

00-00-2010  to  00-00-2010 


4.  TITLE  AND  SUBTITLE 


5a.  CONTRACT  NUMBER 


5b.  GRANT  NUMBER 


5c.  PROGRAM  ELEMENT  NUMBER 


5d.  PROJECT  NUMBER 


5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 


Guide  for  SCAMPI  Appraisals:  Accelerated  Improvement  Method  (AIM) 


6.  AUTHOR(S) 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES)  8.  PERFORMING  ORGANIZATION 

SEI  Administrative  Agent,ESC/XPK,5  Eglin  Street,Hanscom  report  number 

AFB,MA, 01731-2100 

9.  SPONSORING/MONITORING  AGENCY  NAME(S )  AND  ADDRESS(ES )  10.  SPONSOR/MONITOR' S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

This  material  was  created  in  the  performance  of  Federal  Government  Contract  Number 
FA8721-05-C-0003  with  Carnegie  Mellon  University  for  the  operation  of  the  Software  Engineering 
Institute,  a  federally  funded  research  and  development  center.  The  U.S.  Government’s  rights  to  use, 
modify,  reproduce,  release,  perform,  display,  or  disclose  this  material  are  restricted  by  the  Rights  in 
Technical  Data-Noncommercial  Items  clauses  (DFAR  252-227.7013  and  DFAR  252-227.7013  Alternate  I) 
contained  in  the  above  identified  contract. 


14.  ABSTRACT 

The  Software  Engineering  Institute?s  Accelerated  Improvement  Method  (AIM)  incorporates  a  new  version 
of  the  Team  Software  ProcessSM  (TSP  SM)  The  Team  Software  Process  Plus  (TSP+).  TSP+  is  a 
project-based  implementation  of  many  of  the  specific  and  generic  practices  of  Capability  Maturity  Model 
Integration  (CMMI?)  for  Development.  Organizations  using  AIM  for  their  improvement  approach  will  be 
implementing  similar  processes  with  similar  artifacts.  Since  these  implementations  of  CMMI  start  from  a 
common  base,  the  work  of  appraising  such  organizations  against  a  specific  model  scope  should  benefit 
from  this  commonality  of  approach.  This  document  therefore  provides  guidance  to  lead  appraisers  and 
appraisal  teams  unfamiliar  with  TSP+  when  conducting  Standard  CMMI  Appraisal  Method  for  Process 
Improvement  (SCAMPISM)  appraisals  within  organizations  that  use  the  TSP+  as  a  foundational 
operational  practice.  The  intended  benefits  of  this  guidance  are  (1)  to  shorten  the  time  needed  to  prepare 
and  conduct  such  appraisals;  (2)  to  provide  information  helpful  for  appropriate  interpretations;  (3)  and  to 
familiarize  SCAMPI  leads  and  appraisal  teams  with  a  powerful,  proven,  and  available  technology. 


15.  SUBJECT  TERMS 


16.  SECURITY  CLASSIFICATION  OF: 


unclassified 


b.  ABSTRACT 

unclassified 


c.  THIS  PAGE 

unclassified 


17.  LIMITATION  OF 
ABSTRACT 

Public  Release 


18.  NUMBER 
OF  PAGES 


19a.  NAME  OF 
RESPONSIBLE  PERSON 


Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


This  report  was  prepared  for  the 


SEI  Administrative  Agent 
ESC/XPK 
5  Eglin  Street 

Hanscom  AFB,  MA  01731-2100 

The  ideas  and  findings  in  this  report  should  not  be  construed  as  an  official  DoD  position.  It  is  published  in  the 
interest  of  scientific  and  technical  infonnation  exchange. 

This  work  is  sponsored  by  the  U.S.  Department  of  Defense.  The  Software  Engineering  Institute  is  a  federally 
funded  research  and  development  center  sponsored  by  the  U.S.  Department  of  Defense. 

Copyright  201 1  Carnegie  Mellon  University. 

NO  WARRANTY 

THIS  CARNEGIE  MELLON  UNIVERSITY  AND  SOFTWARE  ENGINEERING  INSTITUTE  MATERIAL  IS 
FURNISHED  ON  AN  “AS-IS”  BASIS.  CARNEGIE  MELLON  UNIVERSITY  MAKES  NO  WARRANTIES  OF 
ANY  KIND,  EITHER  EXPRESSED  OR  IMPLIED,  AS  TO  ANY  MATTER  INCLUDING,  BUT  NOT  LIMITED 
TO,  WARRANTY  OF  FITNESS  FOR  PURPOSE  OR  MERCHANTABILITY,  EXCLUSIVITY,  OR  RESULTS 
OBTAINED  FROM  USE  OF  THE  MATERIAL.  CARNEGIE  MELLON  UNIVERSITY  DOES  NOT  MAKE 
ANY  WARRANTY  OF  ANY  KIND  WITH  RESPECT  TO  FREEDOM  FROM  PATENT,  TRADEMARK,  OR 
COPYRIGHT  INFRINGEMENT. 

This  material  was  created  in  the  performance  of  Federal  Government  Contract  Number  FA8721-05-C-0003  with 
Carnegie  Mellon  University  for  the  operation  of  the  Software  Engineering  Institute,  a  federally  funded  research 
and  development  center.  The  U.S.  Government's  rights  to  use,  modify,  reproduce,  release,  perform,  display,  or 
disclose  this  material  are  restricted  by  the  Rights  in  Technical  Data-Noncommercial  Items  clauses  (DFAR  252- 
227.7013  and  DFAR  252-227.7013  Alternate  I)  contained  in  the  above  identified  contract.  Any  reproduction  of 
this  material  or  portions  thereof  marked  with  this  legend  must  also  reproduce  the  disclaimers  contained  on  this 
page. 

For  information  about  SEI  publications,  please  visit  the  library  on  the  SEI  website  (www.sei.cmu.edu/library). 


Table  of  Contents 

Abstract  iii 

1  Audience  and  Purpose  of  this  Guidance  Document  1 

2  AIM/CMMI  Overview  2 

2.1  AIM  Process  Approach  2 

2.1.1  Overview  of  AIM  Process  Assets  3 

2.2  AIM  Process  Elements  3 

2.2.1  Scripts  3 

2.2.2  Forms  4 

2.2.3  Roles  5 

2.2.4  Other  6 

2.2.5  Training  7 

3  Detailed  PA  Appraisal  Guidance  8 

3.1  Project  Management  Processes  8 

3.1.1  Project  Planning  (PP)  9 

3.1.2  Project  Monitoring  and  Control  (PMC)  17 

3.1.3  Integrated  Project  Management  +  I PPD  (I PM)  22 

3.1.4  Risk  Management  (RM)  28 

3.2  Engineering  Processes  32 

3.2.1  Requirements  Management  (REQM)  32 

3.2.2  Requirements  Development  (RD)  36 

3.2.3  Technical  Solution  (TS)  41 

3.2.4  Product  Integration  (PI)  45 

3.2.5  Verification  (VER)  50 

3.2.6  Validation  (VAL)  55 

3.3  Process  Management  Processes  59 

3.3.1  Organizational  Process  Focus  (OPF)  59 

3.3.2  Organizational  Process  Definition  +  IPPD  (OPD)  65 

3.3.3  Organizational  Training  (OT)  69 

3.4  Support  Processes  73 

3.4.1  Configuration  Management  (CM)  73 

3.4.2  Process  and  Product  Quality  Assurance  (PPQA)  77 

3.4.3  Measurement  and  Analysis  (M&A)  82 

3.4.4  Decision  Analysis  and  Resolution  (DAR)  87 

References  89 


SOFTWARE  ENGINEERING  INSTITUTE  |  i 


SOFTWARE  ENGINEERING  INSTITUTE  |  ii 


Abstract 


The  Software  Engineering  Institute’s  Accelerated  Improvement  Method  (AIM)  incorporates  a 
new  version  of  the  Team  Software  ProcessSM  (TSP SM)  The  Team  Software  Process  Plus  (TSP+). 
TSP+  is  a  project-based  implementation  of  many  of  the  specific  and  generic  practices  of  Capabili¬ 
ty  Maturity  Model  Integration  (CMMI®)  for  Development.  Organizations  using  AIM  for  their 
improvement  approach  will  be  implementing  similar  processes  with  similar  artifacts.  Since  these 
implementations  of  CMMI  start  from  a  common  base,  the  work  of  appraising  such  organizations 
against  a  specific  model  scope  should  benefit  from  this  commonality  of  approach. 

This  document  therefore  provides  guidance  to  lead  appraisers  and  appraisal  teams  unfamiliar  with 
TSP+  when  conducting  Standard  CMMI  Appraisal  Method  for  Process  Improvement 
(SCAMPIsm)  appraisals  within  organizations  that  use  the  TSP+  as  a  foundational  operational 
practice.  The  intended  benefits  of  this  guidance  are  ( 1 )  to  shorten  the  time  needed  to  prepare  and 
conduct  such  appraisals;  (2)  to  provide  information  helpful  for  appropriate  interpretations;  (3)  and 
to  familiarize  SCAMPI  leads  and  appraisal  teams  with  a  powerful,  proven,  and  available  technol¬ 
ogy. 
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1  Audience  and  Purpose  of  this  Guidance  Document 


This  document  is  aimed  at  the  lead  appraiser  and  appraisal  team  for  a  Standard  CMMI  Appraisal 
Method  for  Process  Improvement  (SCAMPI)  appraisal  targeting  maturity  levels  2  and  3  of  Capa¬ 
bility  Maturity  Model  Integration  for  Development,  version  1 .2  (CMMI-DEV  V 1 .2)  in  an  organi¬ 
zation  using  the  Accelerated  Improvement  Method  (AIM)  and  Team  Software  Process  Plus 
(TSP+)  as  foundational  practices.  Secondarily,  the  document  is  intended  to  guide  those  responsi¬ 
ble  for  the  preparations  for  such  appraisals. 

SCAMPI  appraisals  focus  on  the  specific  and  generic  practices  of  the  model  scope  under  consid¬ 
eration — that  is,  what  CMMI 14  practices  are  to  be  looked  at  during  the  appraisal,  as  well  as  what 
parts  of  the  organization  are  to  be  reviewed  in  the  appraisal.  Usually,  determining  how  that  model 
scope  connects  to  the  artifacts  and  attributes  of  a  particular  organization  is  unique  to  that  organi¬ 
zation.  However,  when  organizations  use  TSP+  as  the  foundation  of  a  CMMI  implementation 
strategy,  appraisal  teams  have  an  advantage  because  the  training,  standard  artifacts,  and  practices 
are  known  and  generally  available.  Commonality  of  approach  and  artifacts  provides  opportunities 
for  streamlining  the  preparation  and  conduct  of  SCAMPI  appraisals. 

Organizing  the  data  and  artifacts  in  the  standard  AIM  implementation  and  relating  them  to  the 
appropriate  practices  in  the  CMMI  model  will,  we  believe,  provide  valuable  assistance  to  those 
preparing  for  or  performing  a  SCAMPI  appraisal.  This  document  provides  such  guidance,  first  via 
an  overview  of  the  base  TSP+  process  assets,  then  briefly  in  terms  of  a  combined  staged- 
continuous  view  of  CMMI  implementation,  and  finally  practice-by-practice  in  the  fonn  of  prac¬ 
tice  implementation  indicators  (PIIs)  that  are  the  expected  direct  artifacts  of  TSP  usage. 


CMMI  is  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  University. 
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2  AIM/CMMI  Overview 


2.1  AIM  Process  Approach 

The  TSP-based  AIM  approach  combines  the  field-proven  methods  of  TSP  with  the  best  lessons 
learned  when  using  TSP  as  the  foundation  of  model-based  improvement.  The  TSP  has  been  used 
for  more  than  a  decade  with  a  proven  record  of  performance,  starting  with  pilot  projects  prior  to 
2000  and  with  the  official  TSP  release  in  November  2000.  This  consistent  performance  includes 
use  in  both  govermnent  and  commercial  organizations.  Organizations  also  have  combined  suc¬ 
cessfully  the  original  TSP  with  model-based  improvement  methods,  including  the  original  Soft¬ 
ware  Capability  Maturity  Model  and  transitioning  to  CMMI  for  Systems  Engineering/Software 
Engineering  (CMMI-SE/SW)  and  now  CMMI-DEV  VI. 2. 

The  AIM  approach  first  focuses  on  appropriate  training  and  buy-in  with  senior  management,  then 
through  the  chain  of  command  to  middle  and  first-line  management,  and  finally  to  the  developers 
who  staff  self-directed  teams  on  initial  AIM  pilot  projects.  Training  and  piloting  in  every  organi¬ 
zation  is  a  must,  and  is  a  formal  part  of  the  recommended  TSP  introduction  strategy  [Humphrey 
201 1],  After  the  initial  AIM  project  pilots,  the  focus  moves  to  the  organizational  level  as  the  use 
of  TSP+  extends  to  the  process  group,  which  is  responsible  for  CMMI  implementation  in  an  or¬ 
ganization. 

In  contrast  to  “traditional”  CMMI  implementation  using  the  Initiating,  Diagnosing,  Establishing, 
Acting  and  Learning  (IDEAL)  model  and  progressing  maturity  level  by  maturity  level,  AIM  im¬ 
plementation  proceeds  project  by  project,  instantiating  those  CMMI  practices  that  apply  to  devel¬ 
opment  projects.  AIM  processes  directly  cover  the  project  management  process  areas  (PAs)  in 
CMMI  maturity  levels  2  and  3,  excluding  Supplier  Agreement  Management  (SAM),  Project  Plan¬ 
ning  (PP),  Project  Monitoring  and  Control  (PMC),  Integrated  Project  Management  (IPM),  and 
Risk  Management  (RSKM).  The  engineering  process  areas  Requirements  Management  (REQM), 
Requirements  Development  (RD),  Technical  Solution  (TS),  Product  Integration  (PI),  Verification 
(VER),  and  Validation  (VAL)  and  the  support  process  areas  Configuration  Management  (CM), 
Process  and  Product  Quality  Assurance  (PPQA),  Measurement  Analysis  (MA),  and  Decision 
Analysis  and  Resolution  (DAR)  typically  begin  as  hybrid  processes,  combining  AIM  processes 
and  existing  CMMI  processes.  The  remaining  PAs  belong  to  the  process  management  category 
Organization  Process  Focus  (OPF),  Organizational  Process  Definition  (OPD),  and  Organizational 
Training  (OT)  and  form  the  basis  of  process-related  activities.  AIM  includes  establishment  of  an 
engineering  process  group  (EPG)  using  the  same  project  management  disciplines  to  plan  and 
manage  work  that  are  used  in  the  development  projects.  The  EPG  uses  the  support  process  areas 
as  appropriate.  In  a  sense,  the  process  management  PAs  are  to  an  EPG  what  the  engineering  PAs 
are  to  development  teams:  The  development  team  implements  the  engineering  practices  and  the 
EPG  implements  the  process  management  practices. 


Further  discussion  of  TSP  introduction  strategy  appears  in  Leadership,  Teamwork,  and  Trust:  Building  a  Com¬ 
petitive  Software  Capability  by  Watts  S.  Humphrey  and  James  W.  Over  [Humphrey  2011], 
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In  practice,  the  approach  of  creating  hybrid  processes  has  proven  adaptable  and  has  added  value. 
The  key  to  making  this  successful  is  a  skillful  combination  of  the  domain-specific  capabilities 
from  the  organization  and  the  knowledge  and  experience  of  the  AIM  Coach.  The  AIM  Coach  is 
an  SEI-trained  and  certified  professional  who,  among  other  responsibilities,  guides  the  project 
through  the  proper  adoption  of  the  AIM  methodologies. 

2.1.1  Overview  of  AIM  Process  Assets 

AIM  embodies  the  next  generation  of  TSP  process  assets.  While  the  overall  structure  of  those  as¬ 
sets  is  unchanged  from  previous  generations,  AIM  includes  a  new  version  of  TSP  assets  designed 
to  maximize  CMMI  compatibility. 

Use  of  TSP  processes  to  support  an  engineering  process  group  serves  as  an  example  of  how  to 
adapt  the  standard  TSP  assets  to  a  new  organization  and  a  new  domain.  This  acknowledges  pre¬ 
vious  organizations  that  successfully  combined  TSP  and  CMMI,  especially  within  multiple 
groups  at  the  Naval  Air  Systems  Command  (NAVAIR),  and  reflects  the  SEI’s  own  internal  use  of 
the  TSP  [Wall  2007]. 

2.2  AIM  Process  Elements 

The  TSP  is  defined  by  a  set  of  process  elements  that  includes 

•  scripts  to  define  and  guide  specific  work  processes 

•  forms  to  capture  specific  information  generated  by  enacting  one  or  more  scripts  or  that  are 
otherwise  required  by  some  part  of  the  process 

•  role  specifications  to  guide  individuals  on  a  project  in  performing  critical  but  often  non- 
scripted  (and  possibly  non-scriptable)  activities 

•  other  assets  such  as  the  TSP  introduction  strategy,  checklists,  guidelines,  and  specifications 
not  related  to  roles 

•  training  courses  and  authorization  activities  in  the  TSP  and  PSP  technologies 

These  assets  are  summarized  in  the  table  below.  Note  that  the  following  descriptions  and  tables  in 
this  section  are  updated  from  those  listed  in  Section  5  of  the  TSP+  Launch  Notebook,  and  are  pre¬ 
sented  in  the  order  they  appear  in  that  document.2 

2.2.1  Scripts 


Script 

Abbreviation 

TSP+  Script  Name  (please  see  the  TSP+  Launch  Notebook) 

Page 

Reference 

POPS 

Overall  process  operations,  the  initiating  process  improvement  script 

3 

POPS7 

Process  group  formation 

5 

TOPS 

Team  operations,  overall  guidance  for  TSP  introduction 

6 

TOPS4 

Post  launch  TSP  and  TSPm  team  operation 

7 

ANA 

Impact  analysis 

8 

The  TSP+  Launch  Notebook  is  available  to  SEI  Partners  with  a  TSP  license.  For  more  information  on  becoming 
an  SEI  Partner  and  obtaining  a  TSP  license,  see  www.sei.cmu.edu/partners. 
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Script 

TSP+  Script  Name  (please  see  the  TSP+  Launch  Notebook) 

Page 

Abbreviation 

Reference 

CHECKPOINT 

Checkpoint  assessment 

10 

CMAUDIT 

Configuration  management  audit 

12 

CYCLE 

Cycle 

14 

DAR 

Decision  analysis  and  resolution 

16 

DEV 

Overall  development  and  enhancement  process 

18 

HLD 

High-level  design 

19 

IMP 

Implementation 

21 

IMP6 

Unit  test  and  test  development  (step  6  in  script  IMP) 

22 

INS 

Inspection  process  (two  pages) 

23 

LAU 

Team  launch 

26 

LAUm 

Multi-team  launch 

27 

LAU1 

Launch  meeting  1:  launch  overview  and  kickoff 

29 

LAU1A 

Multi-team  launch  meeting  1A:  strategy  presentation 

30 

LAU2 

Launch  meeting  2:  roles  and  goals 

31 

LAU  3 

Launch  meeting  3:  strategy,  process,  support 

32 

LAU3A 

Multi-team  leadership  meeting  3A 

35 

LAU4 

Launch  meeting  4:  overall  team  plan 

36 

LAU  5 

Launch  meeting  5:  quality  plan 

38 

LAU5B 

Multi-team  planning  manager  role  meeting 

39 

LAU5C 

Multi-team  quality  manager  role  meeting 

40 

LAU6 

Launch  meeting  6:  detailed  next-phase  plans 

41 

LAU6B 

Multi-team  planning  manager  meeting,  plan  consolidation 

43 

LAU  7 

Launch  meeting  7:  risk  assessment 

44 

LAU7A 

Multi-team  leadership  meeting  to  plan  the  management  meeting 

46 

LAU8 

Launch  meeting  8:  management  meeting  preparation 

47 

LAU9 

Launch  meeting  9:  wrap-up  management  meeting 

49 

LAU  PM 

Launch  postmortem  meeting:  postmortem  on  the  launch 

50 

LTL 

Leadership  team  launch 

51 

LTL1 

LTL  meeting  1 :  business  goals 

52 

LTL2 

LTL  meeting  2:  leadership  team  goals 

53 

LTL3 

LTL  meeting  3:  team  oversight  strategy 

54 

LTL4 

LTL  meeting  4:  role  team  assignments 

55 

LTL5 

LTL  meeting  5:  role  team  goals  and  responsibilities 

56 

LTLPM 

LTL  postmortem  meeting 

57 

MAINT 

Overall  maintenance  and  enhancement  process 

58 

MTG 

General  meeting  process 

59 

PM 

Project  postmortem 

60 

PMTD 

Postmortem  test  defects 

62 

PREP 

Preparation  script  for  a  multi-team  launch  or  relaunch 

63 

PREPT 

Team  launch  preparation 

64 

2.2.2  Forms 


Form 

Abbreviation 

Form  and  Instructions  Name 

Page 

Reference 

OCR 

Configuration  Change  Request 

3 

CHECKTMDR 

Checkpoint  Team  Member  Data  Review 

6 

CIBPS 

Project  Configuration  Item  Baseline,  Plan,  and  Status 

11 

CIR 

Configuration  Identification  Release 

13 

DAR 

Decision  Analysis  and  Resolution 

15 

DEFECT 

Defect  Reporting  Form 

18 

GOAL 

Team  Goals 

20 
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Form 

Form  and  Instructions  Name 

Page 

Abbreviation 

Reference 

INS 

Inspection  Report 

22 

INV 

Process  Inventory 

24 

ITL 

Issue/Risk  Tracking  Log 

26 

LOGCCR 

Configuration  Change  Request  Log 

28 

LOGCI 

Configuration  Item  Log 

30 

LOGD 

Defect  Recording  Log 

32 

LOGPIP 

Process  Improvement  Proposal  Log 

34 

LOGSPDR 

Standard  Process  Deviation  Request  Log 

36 

LOGT 

Time  Recording  Log 

38 

LOGTRNM 

Team  Member  Training  Log 

40 

LOGTRNR 

Training  Request  Log 

42 

MTG 

Meeting  Report  Form 

44 

PIP 

Process  Improvement  Proposal 

46 

ROLE 

Team  Roles 

48 

ROLEMX 

Role  Assignment  Matrix 

50 

RSIM 

Relevant  Stakeholder  Involvement  Matrix 

52 

SCHED 

Schedule  Planning  Template 

64 

SPDE 

Standard  Process  Deviation  Evaluation 

66 

SPDR 

Standard  Process  Deviation  Request 

68 

SRAM 

Stakeholder  Role  Assignment  Matrix 

70 

STRAT 

Strategic  Planning  Form 

72 

SUMDI 

Defects  Injected  Summary 

74 

SUMDR 

Defects  Removed  Summary 

76 

SUMP 

Plan  Summary  Form 

78 

SUMPD 

Standard  Process  Deviation  Summary 

81 

SUMQ 

Quality  Summary  Form 

83 

SUMS 

Program  Size  Summary 

86 

SUMT 

Development  Time  Summary  Form 

88 

SUMTASK 

Task  Plan  Summary 

90 

SUMTRNS 

Training  Survey  Summary 

92 

TASK 

Task  Planning  Template 

96 

TESTLOG 

Test  Log 

98 

TRNM 

Training  Matrix 

100 

TRNOJT 

On-the-Job  Training 

102 

2.2.3  Roles 


Role 

Description 

Page  Reference 

Meeting 

Meeting  roles  and  responsibilities 

2 

Inspection 

Inspection  roles  and  responsibilities 

3 

TSP  Coach 

TSP  Coach  responsibilities 

4 

Team  Leader 

Team  Leader  responsibilities 

6 

Team  Member 

General  responsibilities  of  team  members 

8 

Customer  Interface 
Manager 

Customer  Interface  Manager  responsibilities 

10 

Design  Manager 

Design  Manager  responsibilities 

12 

Implementation 

Manager 

Implementation  Manager  responsibilities 

14 

Planning  Manager 

Planning  Manager  responsibilities 

16 

Process  Manager 

Process  Manager  responsibilities 

18 

Quality  Manager 

Quality  Manager  responsibilities 

20 

Support  Manager 

Support  Manager  responsibilities 

22 
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Role 

Description 

Page  Reference 

Test  Manager 

Test  Manager  responsibilities 

24 

Process  Group 

Process  Group  responsibilities 

26 

Role  Manager  Team 

Role  Manager  Team  responsibilities 

28 

Lead  Role  Manager 

Lead  Role  Manager  responsibilities 

30 

2.2.4  Other 


Grouping/Name 

Description 

Notes 

Preparation  checklists 

PREPL 

Preparation  for  launch 

PREPR 

Preparation  for  relaunch 

Launch  guidance 

Launch  coach 

Launch  guidelines  for  the  TSP  coach 

Marketing 

Launch  guidelines  for  the  marketing  management 
presentation 

Other  attendees  (2) 

Launch  guidelines  for  the  TSP  coach 

One  for  launches,  one  for  re¬ 
launches 

Senior  Management 

Launch  guidelines  for  the  senior  management 
presentation 

Team  leader  (2) 

Launch  guidelines  for  the  team  leader 

Team  members  (2) 

Launch  guidelines  for  team  members 

Other  pre-launch  assets 

Initial  contact  letter 

TSP  launch  preparation 

Preparation  package 
cover  letter 

TSP  launch  preparation  material 

Preparation  package 
instructions 

TSP  launch  preparation  material 

Default  guidelines 

Planning  guidelines 

SEI-provided  benchmark  planning  metrics 

Quality  guidelines 

SEI-provided  benchmark  quality  metrics 

Executive  assets 


Plan  assessment  check¬ 
list 

Team  plan  review  questions;  a  quick  start  for  an 
executive  reviewing  a  TSP  team’s  plan 

These  assets  can  be  found  in  Win¬ 
ning  with  Software  [Flumphrey 

Quarterly  review 
checklist 

Project  review  questions;  a  quick  start  for  senior 
managers  to  probe  the  status  of  a  TSP  project 

2002], 

TSP  introduction 
strategy 

A  generic  procedure  and  timeline  for  TSP  imple¬ 
mentation  in  an  organization 

Other  specifications  and  assets 


NOTEBOOK 

Storage  for  project  artifacts 

STATUS 

Management  status  report 

SUMMARY 

Project  analysis  report 

TSP  workbook  (individu¬ 
al  and  consolidated) 

Automated  individual  and  team  (consolidated) 
plans  and  actuals  for  size,  effort,  defects,  and 
schedule;  functionally  equivalent  versions  of 
items  under  Forms,  above,  are  included  in  the 

TSP  Workbook 

Excel-based;  provided  by  the  SEI 
as  part  of  the  licensed  TSP  product 
suite 

Checkpoint  review 

A  review  of  the  project  to  date  conducted  by  the 
TSP  coach  or  other  process  expert 

Weekly  meeting 
minutes 

Minutes  from  weekly  team  meetings 
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2.2.5  Training 


Grouping/Name 

Description 

Notes 

Training  and  authorization 

SEI  training  records 

SEI-maintained  records  of  everyone  reported  by 
SEI-authorized  instructors  to  have  finished  any  of 
the  training  classes  listed  below 

Introduction  to  Personal 
Process 

Training  for  team  members  who  are  not  software 
engineers  (2  days) 

PSP  for  Engineers 

Training  for  software  developers  (10  days) 

TSP  Executive  Seminar 

Executive  briefing  on  PSP  and  TSP,  including 
benefits  and  the  TSP  introduction  strategy  (1  day) 

Leading  Development 
Teams 

Training  for  people  managing  TSP  teams  (3 
days) 

PSP  Instructor  Training 

Training  to  become  a  PSP  instructor  (5  days) 

Offered  only  through  the  SEI  or,  in 
Mexico,  Tec  de  Monterrey;  prere¬ 
quisite  is  successful  completion  of 
PSP  for  Engineers 

TSP Launch  Coach 
Training 

Training  to  become  a  TSP  coach  (5  days) 

Offered  only  through  the  SEI  or,  in 
Mexico,  Tec  de  Monterrey;  prere¬ 
quisite  is  successful  completion  of 
PSP  Instructor  Training 

TSP  coach  observation 

Observation  and  mentoring  of  TSP  coach  during 
the  coach’s  first  TSP  launch  (4  or  5  days) 

Offered  only  through  the  SEI  or,  in 
Mexico,  Tec  de  Monterrey;  suc¬ 
cessful  completion  necessary  for 

SEI  authorization 
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3  Detailed  PA  Appraisal  Guidance 


The  following  material  will  provide  in  detail  a  CMMI  practice-by-practice  analysis  of  the  artifacts 
and  the  approach  taken  by  AIM.  Explanations  and  cautions  are  provided  to  help  those  who  are 
unfamiliar  with  AIM.  At  a  minimum,  this  guidance  can  provide  an  appraiser  with  a  starting  list  of 
artifacts  to  request  and  an  opening  line  of  questioning,  phrased  for  the  AIM  methodology. 

3.1  Project  Management  Processes 

Project  planning  and  project  monitoring  and  control  are  strongly  implemented  in  the  TSP  and 
AIM.  The  planning  process  is  well  defined  and  executed  in  the  AIM  launch  process.  The  goal  of 
the  launch  is  to  provide  each  individual  and  the  team  as  a  whole  with  detailed  development  plans 
for  this  cycle  or  iteration.  This  is  accomplished  in  the  launch  meetings  by  developing  a  clear  un¬ 
derstanding  of  the  requirements  and  a  “conceptual  design”  for  the  product.  The  conceptual  design 
lists  the  parts  of  the  product  to  be  developed  and  describes  how  they  will  operate  separately  and  as 
an  integrated  product.  The  plan  is  developed  based  on  the  requirements  and  conceptual  design. 

The  approach  used  by  AIM  and  TSP  for  planning  differs  from  the  classic  MS-Project,  WBS 
(work  breakdown  structure),  or  Gantt-chart  approach.  The  AIM  approach  follows  the  concepts  of 
Lean  Six  Sigma  and  establishes  a  set  of  “value  chain  activities”  and  work  products.  Thus  each 
individual  has  a  set  of  tasks  and  work  products  that  represent  the  work  to  be  done  and  the  prod¬ 
ucts  to  be  developed.  This  list  of  tasks  and  activities  is  presented  in  order  of  execution.  Thus  task 
one  is  worked  first,  task  two  second,  and  so  forth.  This  list  of  tasks  represents  the  WBS  and  is 
carefully  established  and  maintained  (monitored  and  controlled)  as  the  project  executes. 

In  addition  to  focusing  on  value  chain  activities,  the  planning  process  employs  “inch  pebble”  de¬ 
composition.  Each  task  is  8-10  hours  of  duration.  This  inch  pebble  decomposition  allows  for 
earned  value  tracking  and  load  balancing  and  early  warning  on  a  near-real-time  basis. 
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3.1.1  Project  Planning  (PP) 


The  following  table  lists  the  elements  of  the  Project  Planning  process  area  employed  in  the  AIM 
approach. 


TSP 

Reference 

CMMI 

Feature 

CMMI  PA:  PP 
Project 

Planning 

Description 

Direct  Artifact 

Guidance 

PP  SG  1 

Estimates  of 
project  planning 
parameters  are 
established  and 
maintained. 

LAU3,  LAU6 

PP  SP  1.1 

Establish  a  top- 
level  work 
breakdown  struc¬ 
ture  (WBS)  to 
estimate  the 
scope  of  the 
project. 

STRAT  form,  SUMS  form  in  the 
TSP  tool 

Completed  SUMS  (Size  Sum¬ 
mary)  form.  The  SUMS  form  pro¬ 
vides  the  list  of  work  products  and 
associated  attributes  necessary  to 
complete  the  current  iteration. 

For  multiple-iteration  projects  a 
completed  STRAT  (Strategy) 
form.  The  STRAT  form  provides  a 
high-level  view  of  the  multiple 
iterations  that  may  be  necessary 
to  complete  the  project. 

Possibly  a  filled-out  TASK  form 

On  projects  with  multiple  itera¬ 
tions  the  STRAT  form  will 
represent  the  high-level  WBS  and 
estimates  for  the  overall  project. 

The  SUMS  will  be  developed  for 
each  separate  iteration  and 
represents  the  detailed  WBS  and 
estimates  for  that  iteration.  This  is 
an  implementation  of  “Rolling 

Wave”  project  planning. 

An  alternate  practice  is  to  simply 
use  the  SUMS  form  in  the  TSP 
tool  to  represent  the  high-level 

WBS  and  estimates  for  the  overall 
project,  usually  during  meeting  4 
of  the  team’s  launch.  The  team 
would  then  determine  what  will  be 
implemented  during  the  current 
iteration,  resulting  in  a  “new” 

SUMS  for  each  separate  iteration, 
usually  completed  by  the  end  of 
meeting  6  of  the  launch.  A  TASK 
form  may  also  be  created  for  both 
the  overall  plan  and  the  current 
iteration. 

Typically  TSP  projects  do 
not  produce  the  artifacts 
that  one  would  expect  to 
see  from  a  traditional  Mi¬ 
crosoft  Project  Plan  (i.e., 
Gantt  chart,  PERT  chart).  It 
will  save  time  and  energy  if 
the  appraisers  become 
familiar  with  the  TSP  plan¬ 
ning  methodology.  The 
equivalent  data  and  analy¬ 
sis  is  available  with  TSP. 

At  a  minimum,  teams  will 
have  a  representation  of 
the  TSP  SUMS  (Size 
Summary),  which 
represents  a  WBS  in  terms 
of  components,  products, 
or  features.  Most  TSP  tools 
will  have  more. 

The  items  in  the  SUMS  are 
work  products  that  should 
be  produced  by  the  team  to 
complete  the  project.  Typi¬ 
cally  there  will  be  a  process 
(set  of  tasks)  used  to  de¬ 
velop  the  work  products.  It 
is  this  set  of  tasks  for  each 
work  product  that  comprise 
the  task  list  making  up  form 
TASK.  The  SUMS  and  form 
TASK  combine  to  create 
the  equivalent  of  a  very 
detailed  WBS. 
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TSP 

CMMI 

CMMI  PA:  PP 

Direct  Artifact 

Guidance 

Reference 

Feature 

Project 

Planning 

Description 

LAU3,  LAU4, 
LAU6, 

PROBE 

PP  SP  1.2 

Establish  and 

maintain  esti¬ 
mates  of  the 
attributes  of  the 
work  products 
and  tasks. 

SUMS  form,  TASK  form 

Completed  SUMS  form  (plan  and 
actual  base,  modified,  added,  and 
reused  size  for  each  component). 
Completed  STRAT  form.  Com¬ 
pleted  TASK  form.  PROBE  esti¬ 
mation  method  is  either  built  in 
the  tool,  or  is  used  to  generate 
estimates.  Historical  data  is  used 
as  available. 

Need  to  understand 

PROBE  (Proxy  Based  Es¬ 
timation).  Even  if  they  see  a 
two-column  SUMS  sheet, 
there  is  a  WBS  hierarchy 
represented  in  SUMS. 

LAU3, 

STRAT 

PP  SP  1.3 

Define  the 
project  life-cycle 
phases  upon 
which  to  scope 
the  planning 
effort. 

Forms  STRAT,  SUMS,  and  TASK 
in  the  TSP  tool 

The  iterations  are  initially  defined 
for  the  entire  project  on  the 

STRAT  form,  then  are  expanded 
for  each  iteration  in  the  TSP  tool 
(on  the  SUMS  form).  Alternative¬ 
ly,  some  organizations  will  create 
an  initial  SUMS,  in  place  of  form 
STRAT,  which  represents  the 
project  life  cycle. 

The  iteration  plan  (STRAT) 
represents  the  overall  project  life 
cycle  over  multiple  iterations. 

Within  each  iteration,  the  tasks 
associated  with  each  work  prod¬ 
uct  will  usually  represent  a  devel¬ 
opment  life  cycle  for  that  product. 
Each  task  is  associated  with  a 
phase  in  form  TASK  (the  current 
SEI  TSP  tool  allows  for  creation 
of  custom  processes). 

Embedded  in  the  TSP  is 
the  concept  of  an  iterative 
and  incremental  develop¬ 
ment  process  (cyclical). 

Each  project  will  develop 
the  detailed  description 
(strategy)  for  the  incre¬ 
ments  and  iterations 
needed  for  that  project. 
Appraisers  should  ask  to 
see  an  explanation  of  the 
project’s 

cycles/development  strate¬ 
gy- 

Each  iteration  may 
represent  an  execution  of 
the  development  life  cycle. 

LAU3,  LAU4, 
LAU6, 

PROBE 

PP  SP  1.4 

Estimate  the 
project  effort  and 
cost  for  the  work 
products  and 
tasks  based  on 
estimation  ratio¬ 
nale. 

TASK  form 

The  TASK  form  records  effort 
estimate  for  each  task  in  the  next 
iteration  (near-term  detailed  plan). 
Overall  plan  (high-level  plan)  has 
high-level  estimates. 

The  TSP  does  not  include 
dollar  cost  estimation.  For 
most  software  projects, 
effort  estimates  correspond 
directly  to  cost. 

LAUX, 

WEEK 

PP  SG  2 

A  project  plan  is 
established  and 
maintained  as 
the  basis  for 
managing  the 
project. 
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TSP 

CMMI 

CMMI  PA:  PP 

Direct  Artifact 

Guidance 

Reference 

Feature 

Project 

Planning 

Description 

PP  SP  2.1 

Establish  and 

maintain  the 
project’s  budget 
and  schedule. 

SCHED,  WEEK  forms  in  the  TSP 
tool 

SCFIED  form  has  weekly  EV 
(Earned  Value)  schedule  (base¬ 
line,  planned,  actual,  and  pre¬ 
dicted).  So  does  EV  graph  in  TSP 
Excel  tools,  and  the  WEEK  form. 
The  WEEK  form  in  the  Excel  tool 
also  has  milestones. 

Become  familiar  with  the 
planning  tools  and  ap¬ 
proach  used  in  the  TSP. 

Don't  expect  to  see  Gantt 
charts  (although  the  infor¬ 
mation  is  there  in  most  TSP 
tools  to  produce  a  Gantt  if 
needed,  but  TSP  teams  do 
not  find  a  need  for  this). 
Schedule  is  tracked  and 
managed  through  EV  and 
milestones  at  the  overall 
project  level,  and  at  com¬ 
ponent  level. 

LAU7 

PP  SP  2.2 

Identify  and  ana¬ 
lyze  project  risks. 

IRTL  (Issues  and  Risks  Tracking 
Log)  form 

Launch  meeting  9  presentation 
risk  section  and  the  IRTL  (Issue 
and  Risk  Tracking  Log),  and  IR- 
Week  (Issue  and  Risk  Weekly 
Summary) 

Launch  meeting  7  largely 
involves  risk  and  risk  plan¬ 
ning.  Risks  are  recorded, 
assigned,  tracked,  and 
updated  in  IRTL.  Risks  are 
presented  to  management 
in  meeting  9  and  subse¬ 
quent  regularly  held  man¬ 
agement  meetings.  The 
team  manages  risks  as  part 
of  its  weekly  team  meeting. 

Specification 
NOTEBOOK, 
almost  all 

TSP  scripts 
exit  criteria 

PP  SP  2.3 

Plan  for  the 
management  of 
project  data. 

Project  Notebook,  form  LOGCI 
Project  NOTEBOOK  (or  its  equiv¬ 
alent) 

The  Support  Manager  role  has 
been  expanded  to  include  re¬ 
sponsibility  for  CM  for  the  project. 
This  includes  project  data  as 
configuration  Items.  See  the  CM 

PA. 

Notebook  Specification 
defines  the  project  data  that 
is  managed  and  secured. 
Form  LOGCI  lists  the  CIs 
including  PP  CIs. 

LAU3 

PP  SP  2.4 

Plan  for  neces¬ 
sary  resources  to 
perform  the 
project. 

The  people  resources  are  in  the 
TSP  plan. 

Other  resources  are  documented 
in  the  Support  plan  on  form  INV. 
Talk  to  Support  Manager  for  af¬ 
firmation. 

TSP+  provides  very  detailed  indi¬ 
vidual  and  iteration  plans  on  the 
"inch  pebble"  level  (tasks  approx. 

8  hours). 

The  launch  planning 
process  provides  a  com¬ 
prehensive  understanding 
of  the  resource  necessary 
for  the  project. 
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TSP  CMMI  CMMI  PA:  PP  Direct  Artifact  Guidance 

Reference  Feature  Project 

Planning 

Description 

PP  SP  2.5 

Plan  for  know¬ 
ledge  and  skills 
needed  to  per¬ 
form  the  project. 

Required  TSP  training  includes 

training  for  planning  skills. 

In  addition: 

•  Initially  (level  2)  the  Support 
Manager  uses  form  INV  to 
capture  project-specific  train¬ 
ing  needs  in  LAU3  step  8. 

(Other  training  forms  may  or 
may  not  be  used.) 

•  Form  TRNM  (Training  Matrix) 
captures  standard  TSP  course 
training  prerequisites  by  role 
for  a  TSP  team. 

•  For  level  3  (after  formation  of 
the  Process  Group).  The  PG 
role  of  Training  Manager  is  es¬ 
tablished  with  the  resultant 
training  forms:  TRNM, 

TRNOJT  (On-the-Job  Train¬ 
ing),  TRNR  (Training  Re¬ 
quest),  TRNWR  (Training 
Waiver). 

Strong  link  to  the  OT  PA. 

PREPL, 
PREPR, 
Launch  Prep 
Packages, 
STATUS 

PP  SP  2.6 

Plan  the  in¬ 
volvement  of 
identified  stake¬ 
holders. 

RSIM  (Relevant  Stakeholder 
Involvement  Matrix)  form 

Launch  preparation  guidelines  for 
the  senior  manager,  product 
manager,  team  leader,  and  team 
members. 

LAU  meeting  minutes 

Form  RSIM  (Relevant  Stakehold¬ 
er  Involvement  Matrix)  documents 
what  stakeholders/roles  need  to 
be  involved  in  which  scripted 
activities.  ROLES  tab  in  the  TSP 
Excel  tool  defines  team  roles. 

Form  SRAM  Stakeholder  Role 
Assignment  Matrix)  is  used  for 
assigning  roles  identified  in  the 
RSIM  to  individuals. 

The  RSIM  (Relevant 
Stakeholder  Involvement 
Matrix)  provides  a  compre¬ 
hensive  listing  of  stake¬ 
holders  and  their  involve¬ 
ment  in  the  TSP  processes. 

In  particular  for  PP  each  of 
the  launch  meetings  is 
detailed.  Involvement  is 
categorized  as  R,  A,  C,  and 

1  (Responsible,  Accounta¬ 
ble,  Consulted,  Informed). 

The  TSP  has  two  key 
stakeholder  roles:  the  busi¬ 
ness  leader  (senior  man¬ 
ager)  and  the  product  own¬ 
er  (marketing  manager).  All 
business  goals  and  expec¬ 
tations  are  tunneled 
through  the  business  leader 
(e.g.,  schedule,  resource, 
milestones).  All  product 
goals  are  tunneled  through 
the  product  owner  (fea¬ 
tures,  priorities).  These  are 
the  only  stakeholders  au¬ 
thorized  to  give  goals  and 
direction  to  the  project. 
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TSP 

CMMI 

CMMI  PA:  PP 

Direct  Artifact 

Guidance 

Reference 

Feature 

Project 

Planning 

Description 

PP  SP  2.7 

Establish  and 

maintain  the 
overall  project 
plan  content. 

TSP  Tool 

Estimate  and  Actual  columns  in 
SUMS,  SUMP,  SUMQ,  Task. 
Usually  in  TSP  tool. 

Typically,  the  TSP  tool 
used  will  provide  the  me¬ 
chanism  to  establish  and 
maintain  the  plan.  Plan  is 
tracked  and  updated  at 
least  weekly  by  each  indi¬ 
vidual  and  the  team. 

The  Planning  Manager  role 
ensures  the  plan  is  estab¬ 
lished  and  maintained. 

PP  SG  3 

Commitments  to 
the  project  plan 
are  established 
and  maintained. 

LAU, LAU9 

PPSP  3.1 

Review  all  plans 
that  affect  the 
project  to  under¬ 
stand  project 
commitments. 

Meeting  9  presentation,  Meeting  9 
minutes,  individual  and  team 
plans 

Individuals  will  have  developed 
their  own  detailed  plans  for  their 
activities  in  the  iteration. 

Team  and  team  leader 
present  the  plan  to  stake¬ 
holders  during  launch 
meeting  9.  Feedback  is 
incorporated  in  the  plan  by 
the  team.  Because  the 
people  who  do  the  work 
plan  the  work,  that  review  is 
built  in. 

LAU3,  LAU6, 
LAU8, 

PREPL 

PP  SP  3.2 

Reconcile  the 
project  plan  to 
reflect  available 
and  projected 
resources. 

Each  individual  plan  shows  a 
comprehension  of  the  available 
time  and  task  estimates.  Alternate 
plans  are  developed,  if  needed. 
Alternatives  are  recorded  in  the 
launch  meeting  9  presentation 
and  management's  decision  in 
meeting  9  minutes. 

A  TSP  project  starts  with 
allocated  resources.  During 
the  launch,  the  team  may 
determine  that  the  re¬ 
sources  allocated  are  not 
adequate.  Then,  the  team 
generates  alternate  plans, 
balancing  schedule,  scope, 
and  resources. 

LAU,  LAU1, 
LAU9 

PP  SP  3.3 

Obtain  commit¬ 
ment  from  rele¬ 
vant  stakehold¬ 
ers  responsible 
for  performing 
and  supporting 
plan  execution. 

Individuals  develop  their  own 
detailed  personal  plans  based  on 
historical  data  and  estimates  for 
the  current  iteration. 

Meeting  9  presentation  and  meet¬ 
ing  9  minutes 

The  team  members  are 
relevant  stakeholders  and 
their  commitment  is  ob¬ 
tained  throughout  the 
launch  process,  because 
they  produce  the  plan.  The 
business  leader  and  prod¬ 
uct  owner  commitment  is 
received  during  launch 
meeting  9. 

PP  GG  2 

The  process  is 
institutionalized 
as  a  managed 
process. 

PP  GP  2.1 

Establish  and 

maintain  an  or¬ 
ganizational 
policy  for  plan¬ 
ning  and  per¬ 
forming  the 
project  planning 
process. 

Policy  will  be  specific  to  each 
organization. 

This  issue  to  be  addressed 
by  the  AIM  Implementation 
Guide. 
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TSP 

CMMI 

CMMI  PA:  PP 

Direct  Artifact 

Guidance 

Reference 

Feature 

Project 

Planning 

Description 

PP  GP  2.2 

Establish  and 
maintain  the  plan 
for  performing 
the  project  plan¬ 
ning  process. 

The  planning  process  is  defined 
in  detail  in  the  TSP  launch  meet¬ 
ings  and  associated  forms  and 
scripts. 

Launch  Schedule 

Agenda 

PREPL  checklist  filled  out 

Attendee  list  (usually  in  meeting  9 
presentation) 

Schedule,  agenda,  atten¬ 
dees  for  launch  and  re¬ 
launch 

PP  GP  2.3 

Provide  ade¬ 
quate  resources 
for  performing 
the  project  plan¬ 
ning  process, 
developing  the 
work  products, 
and  providing  the 
services  of  the 
process. 

Launches  are  typically  3-4  days 
PREPL  filled  out  (schedule,  facili¬ 
ties,  attendees  in  TSP  tool) 

Although  launches  typically 
take  3-4  days,  development 
will  not  begin  until  a  satis¬ 
factory  plan  is  developed 
by  the  team  and  approved 
by  the  management. 

PP  GP  2.4 

Assign  responsi¬ 
bility  and  authori¬ 
ty  for  performing 
the  process, 
developing  the 
work  products, 
and  providing  the 
services  of  the 
project  planning 
process. 

RSIM  coach  role 

ROLEMX  role  matrix 

PREPL  filled  out  (looking  for 
launch  coordinator,  team  lead, 
and  coach). 

Although  responsibility  for  desig¬ 
nated  activities  during  the  launch 
are  shared,  ultimate  responsibility 
for  the  launch  rests  with  the 
coach. 

The  planning  process  is 
executed  in  the  series  of 
launch  meetings  1-9.  Re¬ 
sponsibility  for  the  success 
of  the  launch  rests  with  the 
coach  (see  RSIM). 
Management  is  responsible 
for  identifying  team  mem¬ 
bers  who  will  participate  in 
the  launch  process  and  be 
part  of  the  team. 

PP  GP  2.5 

Train  the  people 
performing  or 
supporting  the 
project  planning 
process  as 
needed. 

TSP  team  members  must  have 
required  PSP  or  team  member 
training. 

PREPL  filled  out  (looking  for  train¬ 
ing  for  management,  team  mem¬ 
bers,  team  leader) 

The  TSP  coach  guides  the  team 
through  the  launch  process. 

There  is  a  formal  SEI  training  and 
authorization  process  for  TSP 
coaches. 

The  TSP  has  training  re¬ 
quirements  for  TSP  team 
members.  All  SEI- 
authorized  PSP/TSP 
courses  address  the  prin¬ 
ciples  for  PP  needed  for  the 
given  role  (leader,  member, 
developer,  etc.). 

There  is  a  comprehensive 

SEI  training  and  authoriza¬ 
tion  process  for  TSP 
coaches. 
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TSP 

CMMI 

CMMI  PA:  PP 

Direct  Artifact 

Guidance 

Reference 

Feature 

Project 

Planning 

Description 

PP  GP  2.6 

Place  designated 
work  products  of 
the  project  plan¬ 
ning  process 
under  appropri¬ 
ate  levels  of 
control. 

The  planning  manager  is  respon¬ 
sible  for  placing  all  project  plan¬ 
ning  artifacts  into  the  project 
notebook.  The  “project  notebook” 
is  a  term  used  in  TSP  to  refer  to 
the  collection  of  artifacts  describ¬ 
ing  the  project,  its  activities,  and 
the  results.  The  content  of  the 
project  notebook  is  defined  in 
specification  NOTEBOOK. 

The  support  manager  is  respon¬ 
sible  for  developing  a  plan  for  the 
management  of  all  project  data 
identified  in  the  specification 
NOTEBOOK.  This  is  usually  ac¬ 
complished  by  designating  a 
specific  project  folder  on  a  drive 
or  using  a  web-based  file-sharing 
system;  levels  of  control  are  han¬ 
dled  by  setting  access  permis¬ 
sions. 

Informal  configuration 
management  may  be  con¬ 
sidered  appropriate  for  all 
items  identified  in  Specifi¬ 
cation  NOTEBOOK.  It  is  up 
to  the  team  to  determine 
where  and  how  these  items 
will  be  stored  and  who  will 
have  access  to  them  during 
launch  preparation. 

Items  for  formal  configura¬ 
tion  and  data  management 
are  planned  during  launch 
preparation,  CM  processes 
are  observed,  and  planning 
CIs  are  entered  in  form 
LOGCI. 

PP  GP  2.7 

Identify  and  in¬ 
volve  the  rele¬ 
vant  stakehold¬ 
ers  of  the  project 
planning  process 
as  planned. 

RSIM 

Launch  scripts 

PREPL  filled  out,  LAU9  meeting 
report 

The  launch  process  identi¬ 
fies  the  major  planning 
stakeholders.  RSIM  pro¬ 
vides  a  comprehensive  set 
of  stakeholders  and  in¬ 
volvement. 

PP  GP  2.8 

Monitor  and 

control  the 
project  planning 
process  against 
the  plan  for  per¬ 
forming  the 
process  and  take 
appropriate  cor¬ 
rective  action. 

PREPL,  PREPR  shows  launch  is 
planned. 

Launch  meeting  minutes  in  form 
MTG  for  each  meeting. 

Combine  this  with  launch  arti¬ 
facts. 

Weekly  meeting  minutes 

The  team  launch  process 
produces  the  plan. 

The  coach  is  responsible 
for  seeing  that  the  planning 
process  embedded  in  the 
launch  is  on  track  and  fol¬ 
lowed. 

PP  GP  2.9 

Objectively  eva¬ 
luate  adherence 
of  the  project 
planning  process 
against  its 
process  descrip¬ 
tion,  standards, 
and  procedures; 
address  non- 
compliance. 

Checkpoint  report 

See  the  role  of  the  PG  (Process 
Group)  Coaching  Manager. 
Coaching  Manager  report 

TSP  coach  involvement  pre¬ 
launch  (PREPL/PREPR  filled 
out),  during  the  launch  (LAU 
meeting  minutes),  and  after 
(LAUPM). 

The  TSP  coach  will  perform 
a  Checkpoint  to  evaluate 
process  and  work  products. 
During  the  launch,  the 
coach  guides  process  fideli¬ 
ty  for  PP.  As  the  project 
executes,  the  team  leader 
and  planning  and  process 
managers  objectively  eva¬ 
luate. 

When  the  Process  Group 
(PG)  is  formed  the  Coach¬ 
ing  Manager  role  will  objec¬ 
tively  evaluate  the  launch 
process  and  artifacts  for 
each  launch. 
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TSP 

CMMI 

CMMI  PA:  PP 

Direct  Artifact 

Guidance 

Reference 

Feature 

Project 

Planning 

Description 

PP  GP 

2.10 

Review  the  activ¬ 
ities,  status,  and 
results  of  the 
project  planning 
process  with 
higher  level 
management ; 
resolve  issues. 

Launch  meeting  9  presentation. 

You  may  also  ask  for  checkpoint 
reports  and  management  status 
reports. 

PP  GP  3.1 

Establish  and 
maintain  the 
description  of  a 
defined  project 
planning 
process. 

The  TSP+  role  of  Process  Group 
Support  Manager  is  responsible 
for  establishing  and  maintaining 
the  OSSP.  The  OSSP  will  contain 
the  launch  processes,  which  are 
the  main  planning  processes. 

The  Launch  Notebook  (PREPL, 
PREPR,  LAU1-9,  WEEK) 

See  the  role  of  the  PG 

Support  Manager  and  PG 
Process  Manager. 

PP  GP  3.2 

Collect  work 
products,  meas¬ 
ures,  measure¬ 
ment  results,  and 
improvement 
information  de¬ 
rived  from  plan¬ 
ning  and  per¬ 
forming  the 
project  planning 
process  to  sup¬ 
port  the  future 
use  and  im¬ 
provement  of  the 
organization’s 
processes  and 
process  assets. 

The  Process  Asset  Library  and 
associated  collection  mechanisms 
The  organizational  infrastructure 
(including  the  PAL  and  the  mea¬ 
surement  repository)  is  developed 
by  the  Process  Group;  see  OPF, 
OPD. 

Guidelines  to  appraisers: 

The  TSP+  has  been  ex¬ 
panded  to  include  a  PG 
Process  Asset  and  Data 
Repository  Manager. 
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3.1.2  Project  Monitoring  and  Control  (PMC) 

The  following  table  lists  the  elements  of  the  Project  Monitoring  and  Control  (PMC)  process  area 
employed  in  the  AIM  approach. 


TSP 

Reference 

CMMI 

Feature 

CMMI  PA:  PMC 
Project  Monitor¬ 
ing  and  Control 
Description 

Direct  Artifact 

Guidance 

PMC  SG  1 

Actual  perfor¬ 
mance  and 
progress  of  the 
project  are  moni¬ 
tored  against  the 
project  plan. 

WEEK 

PMC  SP  1.1 

Monitor  the  actual 
values  of  the 
project  planning 
parameters 
against  the 
project  plan. 

Minutes  of  the  weekly  team 
meeting  where  the  planning 
data  is  reviewed  and  moni¬ 
tored 

The  TSP  tool  tracks  esti¬ 
mated  and  actual  size,  ef¬ 
fort,  defects  and  schedule. 

See  the  Actual  columns  in 
forms  TASK,  SUMS,  SUMP, 
SUMQ,  SCHED,  EV. 
Management  status  reports 
and  action  items  generated 
from  associated  status 
meetings 

Appraisers  should  become 
familiar  with  the  TSP’s  PROBE 
(Proxy  Based  Estimation). 
Estimates  for  size,  effort,  and 
defects  are  an  integral  part  of 
the  TSP  and  the  launch 
process. 

The  data  collection  mechan¬ 
isms  in  TSP  collect  actual  data 
for  size,  effort,  schedule,  and 
defects.  The  actuals  are  rec¬ 
orded  daily  and  reported 
weekly. 

PMC  SP  1.2 

Monitor  commit¬ 
ments  against 
those  identified  in 
the  project  plan. 

Minutes  of  the  weekly  team 
meeting  where  plan  status, 
including  commitments,  are 
monitored 

Internal  and  External  com¬ 
mitments  are  tracked  as 
milestones  in  the  TSP  tool. 

The  WEEK  form  in  the  tool 
Cycle  PM  reports 

The  team  lead  and  planning 
manager  role  share  responsi¬ 
bility  for  ensuring  commit¬ 
ments  are  reviewed. 

WEEK 

PMC  SP  1.3 

Monitor  risks 
against  those 
identified  in  the 
project  plan. 

IRWEEK  and  IRTL  forms  in 
the  TSP  tool 

Risks  are  reviewed  during 
weekly  team  meetings  and 
status  reporting  to  manage¬ 
ment. 

Risks  are  monitored  in  the 
team  meetings.  In  script 

WEEK  step  5,  Goal  and  Risk 
Reports  the  individual  and 
team  risks  are  reviewed  and 
updated. 

PMC  SP  1.4 

Monitor  the  man¬ 
agement  of 
project  data 
against  the 
project  plan. 

LOGCI  (Configuration  Item 
log),  LOGCCR  (Configura¬ 
tion  change  request  log), 

CCR  (Configuration  Change 
Request),  CIBS  (Configura¬ 
tion  Item  Baseline,  Plan  and 
Status) 

See  the  CM  Project 
NOTEBOOK. 

Role  reports  in  the  team 
meeting  minutes 

The  Support  Manager  role  has 
the  responsibility  for  the  confi¬ 
guration  management  system 
for  the  team.  This  includes 
project  data.  See  the  Support 
Manager  role. 

The  Planning  Manager  has  the 
responsibility  to  monitor  the 
management  of  the  project 
data.  See  the  Planning  Man¬ 
ager  roles  and  responsibilities. 
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TSP 

Reference 

CMMI 

Feature 

CMMI  PA:  PMC 
Project  Monitor¬ 
ing  and  Control 
Description 

Direct  Artifact 

Guidance 

PMC  SP  1.5 

Monitor  stake¬ 
holder  involve¬ 
ment  against  the 
project  plan. 

RSIM  (Relevant  Stakeholder 
Involvement  Matrix)  and  the 
filled  out  ROLE  form 
Checkpoint,  Role  reports  in 
team  meetings 

Management  and  customer 
status  presentations  and 
meeting  minutes 

The  coach,  team  members 
and  team  roles  monitor  stake¬ 
holder  involvement  through 
weekly  meetings,  role  reports, 
status  meetings,  checkpoint 
and  postmortems. 

Internal  stakeholder  involve¬ 
ment  can  be  seen  in  the  indi- 

vidual  team  member  plans  and 
weekly  meeting  minutes.  Two 
primary  stakeholders  (busi¬ 
ness  and  product  owner)  in¬ 
volvement  can  be  seen  in 
launch  meeting  1  and  9  arti¬ 
facts,  in  STATUS  meeting 
reports.  Also,  stakeholder 
evaluation  reports  from  post¬ 
mortems. 


WEEK,  PM,  PMC  SP 
Checkpoint, 

REL 


PMC  SP 


1.6  Periodically  re¬ 
view  the  project's 
progress,  perfor¬ 
mance,  and  is¬ 
sues. 


1.7 


Review  the  ac¬ 
complishments 
and  results  of  the 
project  at  selected 
project  miles¬ 
tones. 


WEEK  form  in  tool,  weekly 
meeting  minutes,  relaunch, 
PM  reports,  Checkpoint 
reports,  and  STATUS  re¬ 
ports 

Within  a  development  cycle, 
the  STATUS  reports  and 
minutes 

For  iterative  development 
across  multiple  development 
cycles:  PM  reports  and  re¬ 
launch  status  reports 


It  would  be  helpful  if  the  ap¬ 
praisers  could  become  familiar 
with  the  TSP  planning  metho¬ 
dology  and  tools  used  by  the 
organization. 

Appraiser  guidance:  For  sin¬ 
gle-cycle  projects  project 
STATUS  presentations  and 
meetings  and  PM  (Postmor¬ 
tem) 

Iteration  (cycle)  reviews  are 
built  in  to  the  TSP  (cycle  PM 
and  relaunch).  These  are  con¬ 
sidered  milestone  reviews  for 
TSP  projects. 


PMC  SG  2 


WEEK  PMC  SP  2.1 


Corrective  actions 
are  managed  to 
closure  when  the 
project's  perfor¬ 
mance  or  results 
deviate  signifi¬ 
cantly  from  the 
plan. 


Earned  value  is  used  in 
determining  the  effective¬ 
ness  of  corrective  actions. 
Corrective  actions  are 
tracked  to  closure  by  creat¬ 
ing  additional  tasks  or 
changes  in  schedule  per¬ 
formance. 


Collect  and  ana¬ 
lyze  the  issues 
and  determine  the 
corrective  actions 
necessary  to 
address  the  is¬ 
sues. 


Issues  are  tracked  on  IRTL 
and  IRWEEK. 

Team  and  Individual  plans 
Team  meeting  minutes 


Appraisers  should  familiarize 
themselves  with  the  TSP 
tracking  capabilities  and  the 
use  of  the  TSP  tool  for  analy¬ 
sis  of  planning  data. 

The  TSP  methodology  and 
tool  provide  exacting  perfor¬ 
mance  management  capabili¬ 
ties.  Activities  in  the  plan  are 
broken  into  tasks  of  8  hours  or 
less.  This  level  of  granularity 
makes  for  very  accurate  week¬ 
ly  earned  value  analysis.  De¬ 
fects  and  defect  injection  rates 
are  estimated  and  measured. 
Schedule  variances  are 
measured  in  days. 

Issues  and  risks  are  discus¬ 
sion  items  in  the  weekly  meet¬ 
ing.  Issues  are  surfaced  in  the 
weekly  meeting,  documented 
in  IRTL,  and  assigned  to 
someone  for  resolution 
(guided  by  team  role). 
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TSP 

CMMI 

CMMI  PA:  PMC 

Direct  Artifact 

Guidance 

Reference 

Feature 

Project  Monitor¬ 
ing  and  Control 
Description 

PMC  SP  2.2 

Take  corrective 

action  on  identi¬ 
fied  issues. 

Issues  are  tracked  on  IRTL 

and  IRWEEK. 

Depending  on  the  corrective 
action  being  taken,  tasks 
may  be  added  to  individual 
plans  to  track  and  monitor 
the  action  to  closure. 

Issues  and  risks  are  discus¬ 
sion  items  in  the  weekly  meet¬ 
ing.  Issues  are  surfaced  in  the 
weekly  meeting,  documented 
in  IRTL,  and  assigned  to 
someone  for  resolution 
(guided  by  team  role).  Issues 
and  risks  are  also  discussed 
in  management  status  meet¬ 
ings. 

PMC  SP  2.3 

Manage  correc¬ 
tive  actions  to 
closure. 

Issues  are  tracked  on  IRTL 

and  IRWEEK. 

Issues  and  risks  are  discus¬ 
sion  items  in  the  weekly  meet¬ 
ing.  Issues  are  surfaced  in  the 
weekly  meeting,  documented 
in  IRTL,  and  assigned  to 
someone  for  resolution 
(guided  by  team  role). 

PMC  GG  3 

The  process  is 
institutionalized 
as  a  defined 
process. 

PMC  GP  2.1 

Establish  and 
maintain  an  orga¬ 
nizational  policy 
for  planning  and 
performing  the 
project  monitoring 
and  control 
process. 

Policy  will  be  specific  to 
each  organization. 

This  issue  to  be  addressed  by 
the  AIM  Implementation 

Guide. 

PMC  GP  2.2 

Establish  and 
maintain  the  plan 
for  performing  the 
project  monitoring 
and  control 
process. 

Weekly  meeting  agendas, 
team  calendars,  postmortem 
agendas,  relaunch  agendas. 
Planning  manager’s  TSP 
plan,  Team  leader  plan, 

Coach  plan 

PMC  in  many  ways  is  built  into 
the  TSP  methodology,  includ¬ 
ing  data  collection,  analysis, 
and  proactive  attention  to 
trends,  deviations,  and  chang¬ 
ing  circumstances.  The  PMC 
plan  includes  activities  by  the 
coach,  planning  manager, 
team  lead  and  the  individual 
team  members.  This  takes 
place  in  weekly  meetings, 
cycle  PMs,  relaunches,  status 
meetings,  and  checkpoints, 
and  are  all  integral  to  the  TSP. 

PMC  GP  2.3 

Provide  adequate 
resources  for 
performing  the 
project  monitoring 
and  control 
process,  develop¬ 
ing  the  work 
products,  and 
providing  the 
services  of  the 
process. 

ROLE  form  in  the  TSP  tool 
(assigned  roles) 

Team  leader  and  all  team 
members  are  responsible. 

TSP  is  a  process  for  self- 
directed  teams.  The  team 
plans,  tracks,  and  resolves 
most  issues.  Role  managers 
manage  different  aspects  of 
the  project  (e.g.,  planning, 
quality,  support). 
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TSP 

Reference 

Role  specs 


Coach, 
team  lead¬ 
er,  team 
member 
role  specifi¬ 
cations 


CMMI 

Feature 

CMMI  PA:  PMC 
Project  Monitor¬ 
ing  and  Control 
Description 

Direct  Artifact 

Guidance 

PMC  GP  2.4 

Assign  responsi¬ 
bility  and  authority 
for  performing  the 
process,  develop¬ 
ing  the  work 
products,  and 
providing  the 
services  of  the 
project  monitoring 
and  control 
process 

ROLE  form  in  the  TSP  tool 
(assigned  roles) 

Team  leader  and  all  team 
members  are  responsible. 

TSP  is  a  process  for  self- 
directed  teams.  The  team 
plans,  tracks,  and  resolves 
most  issues.  Role  managers 
manage  different  aspects  of 
the  project  (e.g.,  planning, 
quality,  support). 

PMC  GP  2.5 

Train  the  people 
performing  or 
supporting  the 
project  monitoring 
and  control 
process  as 
needed. 

LOGTRNM  (Team  Member 
Training  Log) 

TRNM  (Training  Matrix)  of 
necessary  training 

TSP  team  members  must 
have  required  training  (min. 
Fundamentals) 

PREPL  filled  out  (looking  for 
training  for  management, 
team  members,  team  lead¬ 
er) 

The  TSP  coach  guides  the 
team  through  the  launch 
process  and  throughout  the 
development  cycle.  There  is 
a  formal  SEI  training  and 
authorization  process  for 

TSP  coaches. 

The  TSP  has  training  require¬ 
ments  for  TSP  team  members. 
At  a  minimum,  PSP  Funda¬ 
mentals  or  TSP  Team  Member 
training  will  provide  practition¬ 
ers  with  the  principles  for  PP 
and  PMC. 

There  is  a  comprehensive  SEI 
training  and  authorization 
process  for  TSP  coaches. 

PMC  GP  2.6 

Place  designated 
work  products  of 
the  project  moni¬ 
toring  and  control 
process  under 
appropriate  levels 
of  control. 

LOGCI  for  project  notebook 
The  Support  manager  role  is 
responsible  for  CM  for  the 
project.  The  work  products 
from  the  PMC  will  be  CIs  in 
form  LOGCI  and  placed 
under  appropriate  control. 

The  project  notebook 

Typically,  you  would  have  to 
look  at  the  CM  system  sup¬ 
ported  by  the  project  or  or¬ 
ganization. 

Configuration  and  data  man¬ 
agement  are  planned  during 
launch  preparation,  CM 
processes  are  observed,  and 
planning  CIs  are  entered  in 
form  LOGCI.  Typically  team 
and  individual  plans,  status 
presentation,  and  meeting 
minutes  will  be  put  under  the 
appropriate  level  of  control  by 
the  Support  Manager  using 

CM  process. 

PMC  GP  2.7 

Identify  and  in¬ 
volve  the  relevant 
stakeholders  of 
the  project  moni¬ 
toring  and  control 
process  as 
planned. 

LAU9  presentation  to  man¬ 
agement,  management  sta¬ 
tus  reports,  status  meeting 
agendas 

RSIM  (Relevant  Stakeholder 
Involvement  Matrix) 

PMC  GP  2.8 

Monitor  and  con¬ 
trol  the  project 
monitoring  and 
control  process 
against  the  plan 
for  performing  the 
process  and  take 
appropriate  cor¬ 
rective  action. 

Team  meeting  minutes. 
Planning  manager  role  re¬ 
ports.  Status  presentations 
and  meeting  minutes.  IRTL 
(Issue/Risk  Tracking  Log), 
Coach  feedback  and 
Checkpoint 

The  coach,  team  leader,  and 
role  managers  together  moni¬ 
tor  PMC  against  its  plan. 
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Direct  Artifact 


Guidance 


TSP 

Reference 


WEEK 


CMMI 

Feature 


PMC  GP  2.9 


PMC  GP 
2.10 


PMC  GP  3.1 


PMC  GP  3.2 


CMMI  PA:  PMC 
Project  Monitor¬ 
ing  and  Control 
Description 

Objectively  eva¬ 
luate  adherence 
of  the  project 
monitoring  and 
control  process 
against  its 
process  descrip¬ 
tion,  standards, 
and  procedures; 
address  noncom¬ 
pliance. 

Review  the  activi¬ 
ties,  status,  and 
results  of  the 
project  monitoring 
and  control 
process  with 
higher  level  man¬ 
agement  ;  resolve 
issues. 

Establish  and 
maintain  the  de¬ 
scription  of  a 
defined  project 
monitoring  and 
control  process. 


Collect  work 
products,  meas¬ 
ures,  measure¬ 
ment  results,  and 
improvement 
information  de¬ 
rived  from  plan¬ 
ning  and  perform¬ 
ing  the  project 
monitoring  and 
control  process  to 
support  the  future 
use  and  im¬ 
provement  of  the 
organization’s 
processes  and 
process  assets. 


The  TSP  coach  objectively 
evaluates  the  PMC  process 
while  working  with  the  team. 
The  Coach  will  formalize  this 
in  the  Checkpoint  review 


Management  status  meeting 
presentations  and  minutes 
Checkpoint  management 
review 

Launch  meeting  9  presenta¬ 
tion 


The  TSP+  role  of  Process 
Group  Support  Manager  is 
responsible  for  establishing 
and  maintaining  the  OSSP. 
The  OSSP  will  contain  the 
launch  processes,  which  are 
the  main  planning 
processes,  and  Script 
WEEK,  which  is  the  basis  for 
PMC. 

The  Process  Asset  Library 
and  associated  collection 
mechanisms 
The  organizational  infra¬ 
structure  (including  the  PAL 
and  the  measurement  repo¬ 
sitory)  is  developed  by  the 
Process  Group;  see  OPF, 
OPD. 


As  the  project  executes,  the 
Coach  will  objectively  evaluate 
the  PMC  process  as  part  of 
the  coaching  activity.  The 
Coach  will  formalize  this  in  the 
Checkpoint  review,  producing 
the  Checkpoint  Report. 

The  PG  Coaching  Manager 
reviews  checkpoints  from  each 
project  for  compliance. 


Monitoring  the  project’s  status 
against  the  plan  is  a  strength 
of  the  TSP+  process.  This 
includes  weekly  earned  value 
tracking,  schedule  tracking, 
and  quality  tracking  on  a  very 
detailed  level. 


See  the  PG  Support  Manager 
and  PG  Process  Manager 
roles. 


Guidelines  to  appraisers:  The 
TSP+  has  been  expanded  to 
include  a  PG  Process  Asset 
and  Data  Repository  Manager. 
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3.1.3  Integrated  Project  Management  +  IPPD  (IPM) 

The  following  table  lists  the  elements  of  the  Integrated  Project  Management  +  IPPD  (IPM) 
process  area  employed  in  the  AIM  approach. 


TSP 

Reference 

CMMI 

Feature 

CMMI  PA:  IPM 
Integrated  Project 
Management  +  IPPD 
Description 

Direct  Artifact 

Guidance 

IPM  SG  1 

The  project  is  con- 

ducted  using  a  defined 
process  that  is  tailored 
from  the  organization’s 
set  of  standard 
processes. 


PREPL, 
LAU,  Pr  M 
Role 


IPM  SP  1.1 


Establish  and  maintain 
the  project's  defined 
process  from  project 
startup  through  the  life 
of  the  project. 


The  project’s  defined 
process  is  the  tailored 
version  of  the  OSSP  for 
the  project.  This  will  in¬ 
clude  forms,  scripts,  speci¬ 
fications  and  any  ap¬ 
proved  deviations. 
Typically  this  will  be  the 
Project  Notebook  with 
Deviations  (Form  SPDR 
Standard  Process  Devia¬ 
tion  Request). 


In  LAU3  (launch  meeting  3) 
STEP  6  and  7,  the  Process 
Manager  leads  the  team  in 
establishing  the  PDP 
(Projects  defined  process) 
and  is  responsible  for  main¬ 
taining  it  throughout  the 
project. 

The  TSP+  materials  refer  to 
the  PDP  as  the  PSSP 
(Project’s  Set  of  Standard 
Processes) 


LAU 


IPM  SP  1.2 


Planning 
and  Quality 
Guidelines 


LAU3  step 
7 


IPM  SP  1.3 


INV  form 
Support 
Manager 
Role 


Use  the  organizational 
process  assets  and 
measurement  reposi¬ 
tory  for  estimating  and 
planning  the  project’s 
activities. 


Establish  and  maintain 
the  project’s  work 
environment  based  on 
the  organization’s 
work  environment 
standards. 


Estimates  and  project 
plans  are  in  the  TSP  tool. 
Form  SUMS  has  size 
estimates  and  quality  es¬ 
timates. 

Form  TASK  has  effort 
estimates. 


Form  INV  (filled-in  from 
LAU3  step  8) 

TASK  plan  for  support 
manager  role 


Each  of  the  project’s  work 
products  is  listed  in  SUMS 
with  size  estimates  based  on 
historical  data  (see  PROBE). 
SUMS  can  be  seen  as  the 
product  tree. 

Associated  with  each  work 
product  will  be  a  develop¬ 
ment  process,  which  is  the 
set  of  tasks  necessary  to 
produce  that  work  product. 
This  combination  produces  a 
comprehensive  set  of  tasks 
necessary  to  develop  the 
products  and  complete  the 
project. 

LAU4  step  5  explicitly  directs 
reference  to  organizational 
and  project  historical  data. 

The  project’s  support  man¬ 
ager  is  responsible  for  the 
project's  work  environment. 
Form  INV  is  used  to  establish 
what  is  needed. 

The  role  of  the  Process 
Group  Support  Manager  is 
responsible  for  working  with 
the  project  support  managers 
to  ensure  the  work  environ¬ 
ment  is  maintained  across 
the  organization. 
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TSP 

Reference 

CMMI 

Feature 

CMMI  PA:  IPM 
Integrated  Project 
Management  +  IPPD 
Description 

Direct  Artifact 

Guidance 

LAU3, 

LAU4, 

LAU5, 

LAU6, 

LAU7, 

WEEK 

IPM  SP  1.4 

Integrate  the  project 
plan  and  the  other 
plans  that  affect  the 
project  to  describe  the 
project’s  defined 
process. 

The  TSP  tool  provides 
both  individual  and  team 
plans.  The  individual  plans 
are  integrated  to  form  the 
team  plan. 

It  would  be  helpful  if  apprais¬ 
ers  would  become  familiar 
with  the  TSP  planning 
process  and  tools. 

WEEK 

Weekly 

minutes 

STATUS 

Team  lead¬ 
er  and 
process 
manager 
roles 

IPM  SP  1.5 

Manage  the  project 
using  the  project  plan, 
the  other  plans  that 
affect  the  project,  and 
the  project’s  defined 
process. 

Team  meetings  minutes, 
form  IRTL  (individual  and 
team)  form  WEEK 
Management  presenta¬ 
tions  and  meeting  minutes 
STATUS 

Individual  and  team  work¬ 
books  contain  actual  da¬ 
ta/progress  against  the 
plan 

Team  members  track  and 
manage  their  individual 
plans.  The  team  with  direc¬ 
tion  of  the  team  leader  man¬ 
ages  the  Team  Plan. 

LAUPM, 

PM,  Role 
Manager 
Guidelines 

IPM  SP  1.6 

Contribute  work  prod¬ 
ucts,  measures,  and 
documented  expe¬ 
riences  to  the  organi¬ 
zational  process  as¬ 
sets. 

The  PAL,  Data  Repository 

The  PG  (Process  Group) 
Process  Asset  and  Data 
repository  Manager  is  re¬ 
sponsible  for  setting  up  the 
organization’s  PAL  and  data 
repository. 

IPM  SG  2 

Coordination  and  col¬ 
laboration  of  the 
project  with  relevant 
stakeholders  is  con¬ 
ducted. 

PREPL, 

PREPR, 

Preparation 

Guidelines, 

LAU1, 

LAU9 

IPM  SP  2.1 

Manage  the  involve¬ 
ment  of  the  relevant 
stakeholders  in  the 
project. 

RSIM 

Launch  scripts 

PREPL  filled  out,  LAU9 
meeting  report 

Team  meeting  minutes 
Status  meeting  presenta¬ 
tions  and  minutes 

The  launch  process  identifies 
the  major  planning  stake¬ 
holders.  RSIM  provides  a 
comprehensive  set  of  stake¬ 
holders  and  involvement. 
Involvement  is  tracked  by 
reports  in  team  meetings. 

SOFTWARE  ENGINEERING  INSTITUTE  |  23 


TSP 

Reference 

CMMI 

Feature 

CMMI  PA:  IPM 
Integrated  Project 
Management  +  IPPD 
Description 

Direct  Artifact 

Guidance 

LAU3, 

WEEK 

IPM  SP  2.2 

Participate  with  rele¬ 
vant  stakeholders  to 
identify,  negotiate,  and 
track  critical  depen¬ 
dencies. 

IRTL 

Milestones  in  plan 

Team  meeting  minutes 
Status  presentations  and 
minutes 

Filled-in  from  STRAT 

Internal  dependencies  are 
reflected  in  the  development 
strategy  and  the  task  order. 
Milestones  can  also  be  used 
to  track/identify  internal  and 
external  dependencies.  They 
may  also  be  tracked  as  risks. 
Internal  dependencies  are 
also  communicated  every 
week.  Three  questions  asked 
in  a  weekly  meeting  are  (1) 
What  did  you  do  last  week? 

(2)  What  will  you  do  this 
week?  (3)  Is  there  anything 
blocking  you? 

In  the  TSP,  critical  depen¬ 
dencies  are  identified  and 
tracked  in  (1)  the  risk  (IRTL) 
and  IRWEEK,  and  (2)  devel¬ 
opment  strategy  (risk  based, 
dependency  based,  business 
value  based,  architecture 
based). 

Critical  dependencies  are 
explicitly  referenced  in  LAU3 
step  4,  LAU4  step  8,  LAU6 
step  5. 

IPM  SP  2.3 

Resolve  issues  with 
relevant  stakeholders. 

IRTL,  TASK,  WEEK 

Most  issues  are  tracked  in 
the  IRTL  (Issue  and  Risk 
Tracking  Log).  Some  could 
also  be  tracked  as  tasks 
and/or  milestones.  Reviews 
and  inspections  are  identified 
as  tasks  in  the  plan.  These 
are  assigned  to  internal  and 
external  reviewers  when 
needed.  Review  artifacts  are 
captured  at  least  in  task 
completion,  time  logs,  and 
defect  logs. 

IPM  SG  3 

The  project  is  ma¬ 
naged  using  IPPD 
principles. 

PREPL, 

LAU1, 

PREPR, 

LAU1, 

LAU2 

Senior 
manage¬ 
ment  and 
marketing 
discussion 
guidelines 

IPM  SP  3.1 

Establish  and  maintain 
a  shared  vision  for  the 
project. 

LAU1  Business  and  Prod¬ 
uct  goals  and  success 
criteria 

Look  for  business  and  prod¬ 
uct  goal  presentations  from 
launch  meeting  1. 

Role  Man¬ 
ager  Teams 

IPM  SP  3.2 

Establish  and  maintain 
the  integrated  team 
structure  for  the 
project. 

PREP 

Look  for  Role  Teams 
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TSP 

CMMI 

CMMI  PA:  IPM 

Direct  Artifact 

Guidance 

Reference 

Feature 

Integrated  Project 
Management  +  IPPD 
Description 

PREP 

IPM  SP  3.3 

Allocate  requirements, 
responsibilities,  tasks, 
and  interfaces  to 
teams  in  the  integrated 
team  structure. 

PREP 

IPM  SP  3.4 

Establish  and  maintain 
integrated  teams  in  the 
structure. 

Role  manager  teams,  team 
roles,  team  goals 

TSPm  Role 
Manager 
Team 
Responsi¬ 
bilities 

IPM  SP  3.5 

Ensure  collaboration 
among  interfacing 
teams. 

IPM  GG  2 

The  process  is  institu¬ 
tionalized  as  a  ma¬ 
naged  process. 

IPM  GP  2.1 

Establish  and  maintain 
an  organizational  poli¬ 
cy  for  planning  and 
performing  the  inte¬ 
grated  project  man¬ 
agement  process. 

Policy  will  be  specific  to 
each  organization. 

This  issue  to  be  addressed 
by  the  Implementation  Guide. 

IPM  GP  2.2 

Establish  and  maintain 
the  plan  for  performing 
the  integrated  project 
management  process. 

Launch  schedule  and 
agenda 

PREPL  checklist  filled  out 

Launch  attendee  list 
(usually  in  meeting  9 
presentation) 

Team  meeting  schedule 
and  agendas 

All  team  members  plus  the 
coach  are  present  for  the 
launch  meetings  where  the 
majority  of  IPM  takes  place. 

IPM  GP  2.3 

Provide  adequate 
resources  for  perform¬ 
ing  the  integrated 
project  management 
process,  developing 
the  work  products,  and 
providing  the  services 
of  the  process. 

PREPL  filled  out  (sche¬ 
dule,  facilities,  attendees 
for  different  meetings) 

Launch  schedule,  team 
meeting  schedule,  status 
meeting  schedule  with  atten¬ 
dees 

Individual  plans  with  sche¬ 
dule  and  tasks  including  role 
tasks 

IPM  GP  2.4 

Assign  responsibility 
and  authority  for  per¬ 
forming  the  process, 
developing  the  work 
products,  and  provid¬ 
ing  the  services  of  the 
integrated  project 
management  process. 

ROLEMX  role  assignment 
matrix 

PREPL  filled  out  (looking 
for  launch  coordinator, 
team  lead,  and  coach) 

The  coach  is  responsible  for 
ensuring  the  TSP  process  is 
followed.  The  planning  man¬ 
ager,  team  lead,  and  team 
members  have  responsibili¬ 
ties  assigned  in  the  scripts 
and  roles. 
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TSP 

Reference 


Support 
manager 
role  and 
role  teams 


CMMI  CMMI  PA:  IPM 


Feature  Integrated  Project 
Management  +  IPPD 
Description 


IPM  GP  2.5 


Train  the  people  per¬ 
forming  or  supporting 
the  integrated  project 
management  process 
as  needed. 


IPM  GP  2.6  Place  designated  work 
products  of  the  inte¬ 
grated  project  man¬ 
agement  process  un¬ 
der  appropriate  levels 
of  control. 


IPM  GP  2.7  Identify  and  involve 
the  relevant  stake¬ 
holders  of  the  inte¬ 
grated  project  man¬ 
agement  process  as 
planned. 


IPM  GP  2.8 


Monitor  and  control 
the  integrated  project 
management  process 
against  the  plan  for 
performing  the 
process  and  take  ap¬ 
propriate  corrective 
action. 


Direct  Artifact 


TSP  team  members  must 
have  required  PSP  or 
team  member  training 
TRNM  (Training  Matrix) 
LOGTRNM  (Log  of  Team 
Member  Training) 

PREPL  filled  out  (looking 
for  training  for  manage¬ 
ment,  team  members, 
team  leader) 

There  is  a  comprehensive 
SEI  training  and  authoriza¬ 
tion  process  for  TSP 
coaches. 

LOGCI  of  the  project 
notebook  if  the  notebook 
is  put  under  formal  CM 
otherwise  appropriate 
level  of  control. 

The  Support  Manager  role 
is  responsible  for  CM  for 
the  project.  The  work 
products  from  the  launch 
will  be  CIs  in  form  LOGCI 
and  placed  under  appro¬ 
priate  control.  The  project 
notebook  may  be  under 
informal  configuration 
control. 

Typically,  you  would  have 
to  look  at  the  CM  system 
supported  by  the  project  or 
organization  (a  protected 
folder  on  a  drive,  or  full 
CM  with  CVS). 

RSIM  (Relevant  Stake¬ 
holder  Involvement  Matrix) 
PREPL  filled  out,  LAU9 
meeting  report 
Team  meetings  presenta¬ 
tions  and  minutes 
Status  meetings  presenta¬ 
tion  and  minutes 

PREPL,  PREPR  shows 
launch  is  planned. 

Launch  meeting  minutes 
in  form  MTG  for  each 
meeting 

Combine  this  with  launch 
artifacts. 

Weekly  meeting  minutes 


Guidance 


The  TSP  has  training  re¬ 
quirements  for  TSP  team 
members.  All  SEI-authorized 
PSP/TSP  courses  address 
the  planning  principles 
needed  for  the  given  role 
(e.g.,  leader,  member,  devel¬ 
oper). 

The  TSP  coach  guides  the 
team  through  the  launch 
process.  There  is  a  formal 
SEI  training  and  authoriza¬ 
tion  process  for  TSP  coach¬ 
es. 

Configuration  and  data  man¬ 
agement  are  planned  during 
launch  preparation,  CM 
processes  are  observed,  and 
planning  CIs  are  entered  in 
form  LOGCI.  Formal  or  in¬ 
formal  CM  methods  may  be 
appropriate. 


The  coach  is  responsible  for 
ensuring  that  the  planning 
process  embedded  in  the 
launch  is  on  track  and  fol¬ 
lowed. 
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TSP 

Reference 


CMMI 

Feature 

CMMI  PA:  IPM 
Integrated  Project 
Management  +  IPPD 
Description 

Direct  Artifact 

Guidance 

IPM  GP  2.9 

Objectively  evaluate 
adherence  of  the  inte¬ 
grated  project  man¬ 
agement  process 
against  its  process 
description,  standards, 
and  procedures;  ad¬ 
dress  noncompliance. 

See  the  role  of  Coaching 
Manager. 

TSP  coach  involvement 
pre-launch 

(PREPL/PREPR  filled 
out),  during  the  launch 
(LAU  meeting  minutes) 
and  after  (LAUPM). 

During  the  launch,  the  coach 
guides  process  fidelity  for  PP 
and  IPM.  As  the  project  ex¬ 
ecutes,  the  team  leader,  and 
planning  and  process  man¬ 
agers  objectively  evaluate. 
When  the  Process  Group 
(PG)  is  formed  the  Coaching 
Manager  role  will  objectively 
evaluate  the  launch  process 
and  artifacts. 

The  PG  Process  Manager  is 
responsible  for  ensuring  that 
each  Project  Process  Man¬ 
ager  has  the  team  using  the 
correct  processes. 

IPM  GP 

2.10 

Review  the  activities, 
status,  and  results  of 
the  integrated  project 
management  process 
with  higher  level  man¬ 
agement  ;  resolve 
issues. 

Launch  meeting  9  presen¬ 
tation.  You  may  also  ask 
for  checkpoint  reports  and 
management  status  re¬ 
ports. 

Weekly  meeting  minutes 
Management  STATUS 
report  and  minutes 

IPM  GP  3.1 

Establish  and  maintain 
the  description  of  a 
defined  integrated 
project  management 
process. 

The  TSP+  role  of  Process 
Group  Support  Manager  is 
responsible  for  establish¬ 
ing  and  maintaining  the 
OSSP.  The  OSSP  will 
contain  the  launch 
processes,  which  are  the 
main  planning  processes. 
The  Launch  Notebook 
(PREPL,  PREPR,  LAU1-9, 
WEEK) 

See  the  PG  Support  Manag¬ 
er  and  PG  Process  Manager 
roles. 

IPM  GP  3.2 

Collect  work  products, 
measures,  measure¬ 
ment  results,  and  im¬ 
provement  information 
derived  from  planning 
and  performing  the 

IPM  process  to  sup¬ 
port  the  future  use  and 
improvement  of  the 
organization’s 
processes  and 
process  assets. 

The  Process  Asset  Library 
and  associated  collection 
mechanisms 

The  organizational  infra¬ 
structure  (including  the 

PAL  and  the  measurement 
repository)  is  developed 
by  the  Process  Group;  see 
OPF,  OPD. 

The  TSP+  has  been  ex¬ 
panded  to  include  a  PG 
Process  Asset  and  Data 
Repository  Manager. 

SOFTWARE  ENGINEERING  INSTITUTE  |  27 


3.1.4  Risk  Management  (RM) 


The  following  table  lists  the  elements  of  the  Risk  Management  (RM)  process  area  employed  in 
the  AIM  approach. 


TSP/PSP 

Reference 

CMMI 

CMMI  PA:  RSKM 

Risk  Management 

Direct  Artifact 

Guidance 

RSKM 

SG  1 

Preparation  for  risk  manage¬ 
ment  is  conducted. 

LAU7,  ITL, 
WEEK,  TL 
role,  Ping 

Mgr  role 

RSKM 

SP  1.1 

Determine  risk  sources  and 
categories. 

Form  ITL  (Issue/Risk 
Log)  and  Instructions 

The  instructions  for  the  ITL 
form  provide  an  initial  set  of 
sources  and  categories. 

LAU7,  ITL, 

TL  role 

RSKM 

SP  1.2 

Define  the  parameters  used  to 
analyze  and  categorize  risks, 
and  the  parameters  used  to 
control  the  risk  management 
effort. 

Form  ITL  (Issue/Risk 
Log)  and  Instructions 
LAU7  step  3 

Launch  Meeting  7  is  de¬ 
signed  to  lead  the  project 
through  a  risk  assessment. 
See  Script  LAU7. 

LAU7,  ITL, 
WEEK 

RSKM 

SP  1.3 

Establish  and  maintain  the 
strategy  to  be  used  for  risk 
management. 

Form  ITL  (Issue/Risk 
Log)  and  Instructions 
LAU7  step  3 

Risk  management  strategy 
is  described  in  the  forms 
and  scripts. 

RSKM 

SG  2 

Risks  are  identified  and  ana¬ 
lyzed  to  determine  their  relative 
importance. 

LAU7,  ITL, 

TL  role,  TM 
role 

RSKM 

SP  2.1 

Identify  and  document  the  risks. 

Form  ITL  (Issue/Risk 
Log)  and  Instructions 
LAU7  step  3,  ITL 
(IRTL  in  SEI  work¬ 
books) 

While  all  risks  at  a  threshold 
will  be  assigned,  appraisal 
teams  should  understand 
that  risks  may  be  assigned 
to  individual  team  members, 
or  to  a  team  role. 

LAU7,  ITL, 

TL  role,  TM 
role,  other 
roles 

RSKM 

SP  2.2 

Evaluate  and  categorize  each 
identified  risk  using  the  defined 
risk  categories  and  parameters, 
and  determine  its  relative  priori¬ 
ty- 

Form  ITL  (Issue/Risk 
Log)  and  Instructions 
LAU7  step  3,  ITL 
(IRTL  in  SEI  work¬ 
books) 

The  ITL  and  instructions 
have  priority  formulated  as 
the  risk/likelihood  combina¬ 
tion.  Therefore  FIH  (high 
likelihood  and  high  impact) 
would  be  the  highest  priori¬ 
ty,  etc. 

RSKM 

SG  3 

Risks  are  handled  and  miti¬ 
gated,  where  appropriate,  to 
reduce  adverse  impacts  on 
achieving  objectives. 

LAU7,  ITL, 

TL  role,  TM 
role,  other 
roles 

RSKM 

SP  3.1 

Develop  a  risk  mitigation  plan 
for  the  most  important  risks  to 
the  project,  as  defined  by  the 
risk  management  strategy. 

LAU7  step  4,  ITL 
(IRTL  in  SEI  work¬ 
books)  or  equivalent 

LAU7  step  4  requires  that  a 
risk  plan  be  developed  for 
all  risks  that  are  high  or 
medium  priority 
(HH,HM,MH,MM). 

WEEK,  ITL 

RSKM 

SP  3.2 

Monitor  the  status  of  each  risk 
periodically  and  implement  the 
risk  mitigation  plan  as  appropri¬ 
ate. 

WEEK,  ITL  (IRTL  in 

SEI  workbooks) 

See:  Script  WEEK  step  5. 

RSKM 

GG  2 

The  process  is  institutionalized 
as  a  managed  process. 

RSKM 

GP  2.1 

Establish  and  maintain  an  or¬ 
ganizational  policy  for  planning 
and  performing  the  risk  man¬ 
agement  process. 

Policy  will  be  specific 
to  each  organization. 

This  issue  to  be  addressed 
by  the  Implementation 

Guide. 
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TSP/PSP 

CMMI 

CMMI  PA:  RSKM 

Direct  Artifact 

Guidance 

Reference 

Risk  Management 

RSKM  Establish  and  maintain  the  plan 
GP  2.2  for  performing  the  risk  man¬ 
agement  process. 


RSKM  Provide  adequate  resources  for 

GP  2.3  performing  the  risk  manage¬ 

ment  process,  developing  the 
work  products,  and  providing 
the  services  of  the  process. 


Schedule  and  agenda 
for  the  launch  and  the 
team  meetings. 
Launch  meeting  7  is 
dedicated  to  risk  and 
risk  management. 
PREPL  checklist 
(filled  out) 

Attendee  list  (usually 
in  meeting  9  presen¬ 
tation) 

Script  WEEK 


PREPL  filled  out 


Planning  and  execution  of 
the  launch  includes  plan¬ 
ning  for  risk  management  in 
meeting  LAU7;  weekly 
meetings  have  a  standard 
step  to  evaluate  &  update 
risks. 

The  team  meetings  are 
attended  by  all  on  the  team 
and  have  a  schedule  and 
agenda. 

Risks  are  part  of  the  man¬ 
agement  status  meetings; 
see  Specification  STATUS. 

Time  and  resources  for  Risk 
Management  are  planned 
for  in  the  launch  and  the 
weekly  meetings  and  status 
meetings. 

Tasks  may  also  be  found  in 
individual  plans  for  work 
associated  with  the  execu¬ 
tion  of  a  risk  mitigation  plan. 


RSKM  Assign  responsibility  and  au- 

GP  2.4  thority  for  performing  the 

process,  developing  the  work 
products,  and  providing  the 
services  of  the  risk  manage¬ 
ment  process. 


Team  Lead  role  is 
specifically  charged 
with  responsibility; 
may  delegate  as 
shown  in  ITL  (IRTL  in 
SEI  workbooks) 


The  team  lead  is  responsi¬ 
ble  for  leading  the  team 
through  the  risk  assessment 
in  LAU7  and  leading  the 
team  through  the  team  and 
management  meetings. 


RSKM 
GP  2.5 


RSKM 
GP  2.6 


Train  the  people  performing  or 
supporting  the  risk  manage¬ 
ment  process  as  needed. 


Place  designated  work  products 
of  the  risk  management  process 
under  appropriate  levels  of 
control. 


TSP  TL  Training  in¬ 
structs  on  LAU7 
OJT  for  TL  and  the 
team  as  necessary 

LOGCI  if  the  decision 
is  made  to  put  the 
project  notebook 
under  formal  CM. 
Otherwise  the  project 
notebook  will  be  put 
under  appropriate 
level  of  control. 

The  Support  Manager 
role  is  responsible  for 
CM  for  the  project. 
The  work  products 
from  the  launch  will 
be  CIs  in  form  LOGCI 
and  placed  under 
appropriate  control. 
The  project  notebook 
Typically,  you  would 
have  to  look  at  the 
CM  system  supported 
by  the  project  or  or¬ 
ganization  (a  pro¬ 
tected  folder  on  a 
drive,  or  full  CM  with 
CVS). 


TSP  Team  leader  training 


Configuration  and  data 
management  are  planned 
during  launch  preparation, 
CM  processes  are  ob¬ 
served,  and  planning  CIs 
are  entered  in  form  LOGCI. 
Formal  or  informal  CM  me¬ 
thods  will  be  chosen. 
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TSP/PSP 

Reference 


Direct  Artifact 


Guidance 


TSP  Coach 
role 

TSP  TL  role 


STATUS 
spec 
TL  role 


CMMI  CMMI  PA:  RSKM 
Risk  Management 


RSKM 
GP  2.7 


RSKM 
GP  2.8 


RSKM 
GP  2.9 


Identify  and  involve  the  relevant 
stakeholders  of  the  risk  man¬ 
agement  process  as  planned. 


Monitor  and  control  the  risk 
management  process  against 
the  plan  for  performing  the 
process;  and  take  appropriate 
corrective  action. 


Objectively  evaluate  adherence 
of  the  risk  management  process 
against  its  process  description, 
standards,  and  procedures; 
address  noncompliance. 


RSIM 

Launch  scripts 
PREPL  filled  out, 
LAU9  meeting  report 


PREPL,  PREPR 
shows  launch  is 
planned. 

Launch  meeting  mi¬ 
nutes  in  form  MTG  for 
each  meeting 
Combine  this  with 
launch  artifacts. 
Weekly  meeting  mi¬ 
nutes 

Checkpoint 
Team  meeting  sche¬ 
dule 

Checkpoint  report 
TSP  Coach  involve¬ 
ment  pre-launch 
(PREPL/PREPR  filled 
out),  during  the 
launch  (LAU  meeting 
minutes)  and  after 
(LAUPM). 


See  the  role  of  the  PG 
(Process  Group) 
Coaching  Manager. 
Coaching  Manager 
report 


RSKM 
GP  2.10 


Review  the  activities,  status, 
and  results  of  the  risk  manage¬ 
ment  process  with  higher  level 
management ;  resolve  issues. 


STATUS  report  to 
higher  level  manage¬ 
ment 


RSKM  Establish  and  maintain  the 
GP  3.1  description  of  a  defined  risk 
management  process. 


The  TSP+  role  of 
Process  Group  Sup¬ 
port  Manager  is  re¬ 
sponsible  for  estab¬ 
lishing  and 
maintaining  the 


OSSP.  The  OSSP  will 


contain  the  launch 
processes,  which  are 
the  main  planning 
processes. 

The  Launch  Notebook 


(PREPL,  PREPR, 
LAU1-9,  WEEK) 


The  launch  process  identi¬ 
fies  the  major  planning 
stakeholders.  RSIM  pro¬ 
vides  a  comprehensive  set 
of  stakeholders  and  in¬ 
volvement. 

The  team  launch  process 
produces  the  plan,  including 
the  risk  plan. 

The  coach  is  responsible  for 
seeing  that  the  risk  planning 
process  embedded  in  the 
launch  is  on  track  and  fol¬ 
lowed. 


The  TSP  Coach  will  perform 
a  Checkpoint  to  evaluate 
process  and  work  products. 
During  the  launch,  the 
coach  guides  process  fideli¬ 
ty  for  RSKM.  As  the  project 
executes,  the  team  leader, 
and  planning  and  process 
managers,  objectively  eva¬ 
luate. 

When  the  Process  Group 
(PG)  is  formed  the  Coach¬ 
ing  Manager  role  will  objec¬ 
tively  evaluate  the  launch 
process  and  artifacts  for 
each  launch. 


See  the  PG  Support  Man¬ 
ager  and  PG  Process  Man¬ 
ager  roles. 
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TSP/PSP 

Reference 

CMMI 

CMMI  PA:  RSKM 

Risk  Management 

Direct  Artifact 

Guidance 

RSKM 

GP  3.2 

Collect  work  products,  meas¬ 
ures,  measurement  results,  and 
improvement  information  de¬ 
rived  from  planning  and  per¬ 
forming  the  RSKM  process  to 
support  the  future  use  and  im¬ 
provement  of  the  organization’s 
processes  and  process  assets. 

The  Process  Asset 
Library  and  asso¬ 
ciated  collection  me¬ 
chanisms 

The  organizational 
infrastructure  (includ¬ 
ing  the  PAL  and  the 
measurement  reposi¬ 
tory)  is  developed  by 
the  Process  Group. 

See  OPF,  OPD. 

The  TSP+  has  been  ex¬ 
panded  to  include  a  PG 
Process  Asset  and  Data 
Repository  Manager. 
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3.2  Engineering  Processes 

The  engineering  PAs  include  Requirements  Management  (REQM),  Requirements  Development 
(RD),  Technical  Solution  (TS),  Product  Integration  (PI),  Verification  (VER),  and  Validation 
(VAL).  Each  organization  adopting  AIM  will  have  its  own  domain  and  environment  that  will 
need  to  be  reflected  in  the  engineering  processes,  tools,  and  methods  used  by  the  organization. 
This  will  necessitate  a  flexible  approach  for  AIM  implementation.  The  AIM  implementation 
guidance  will  describe  the  recommended  procedure  for  working  with  the  organization  to  adapt 
and  integrate  the  appropriate  engineering  methods,  tools,  and  processes  into  the  organization’s 
standard  process.  This  integration  will  establish  the  standard  process  for  the  organization  as  well 
as  assuring  CMMI  compliance. 

The  guidance  documents  that  follow  were  developed  from  the  PSP/TSP  and  were  not  augmented 
with  tools,  methods,  and  procedures  representation  any  single  development  domain  or  customer 
use  case.  There  are  practices  and  direct  artifacts  missing  or  only  partially  fulfilling  CMMI  expec¬ 
tations.  This  is  understandable  as  the  organization  will  have  made  or  will  need  to  make  implemen¬ 
tation  decisions  specific  to  the  organization’s  development  domain  and  environment.  For  exam¬ 
ple,  the  configuration  management  system  can  be  implemented  by  simple  manual  methods  or  by 
employing  a  fully  automated  CM  system. 

3.2.1  Requirements  Management  (REQM) 

The  following  table  lists  the  elements  of  the  Requirements  Management  (REQM)  process  area 
employed  in  the  AIM  approach. 


TSP/PSP 

CMMI 

CMMI  PA:  REQM 

Direct  Artifact 

Guidance 

Reference 

Feature 

Requirements 

Management 

REQM  SG 

Requirements  are  ma- 

Appropriate  development  me- 

1 

naged  and  inconsisten- 

thodolog(ies)  will  need  to  be 

cies  with  project  plans 

adopted  by  the  organization. 

and  work  products  are 

These  methodologies  may 

identified. 

have  their  own  artifacts  that  will 
need  to  be  substituted  for 
those  referenced  in  the  TSP+. 

Overall  comments  for  REQM: 

1)  Scripts  REQ  and  ANA  point 
to  SRS  and  ERS  that  currently 
have  no  specifications  or  sam¬ 
ples. 

2)  Processes  are  very  high- 
level  and  probably  cannot  be 
directly  implemented  without 
consulting  support  or  utilizing 
existing  processes. 

3)  See  the  AIM  roles  of 

(a)  Senior  Management  provid¬ 
ing  business  direction 

(b)  Marketing/Customer  Rep¬ 
resentative  providing  product 
specifications,  and 

(c)  Customer  Interface  Manag¬ 
er  providing  detail  specifica¬ 
tions 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  REQM 

Requirements 

Management 

Direct  Artifact 

Scripts  REQ, 

REQM  SP 

Develop  an  understand- 

Market  study  results, 

ANA 

1.1 

ing  with  the  require¬ 
ments  providers  on  the 
meaning  of  the  re¬ 
quirements. 

SRS,  ERS,  impact 
analyses,  or  equiva¬ 
lents  are  called  out  by 
REQ  and/or  ANA.  Also, 
where  marketing  goals 
in  LAU1  are  very  close 
to  actual  requirements, 
the  LAU1  presentation 
and  SUMS  may  or  may 
not  reflect  this  under¬ 
standing. 

Scripts 

REQM  SP 

Obtain  commitment  to 

Launch  and  relaunch 

LAU1,  LAU9 

1.2 

the  requirements  from 
the  project  participants. 

plans  (esp.  LAU9  pres¬ 
entations  in  launches), 
and  impact  analyses 

Customer 

REQM  SP 

Manage  changes  to  the 

SRS  changes,  impact 

Interface  and 

1.3 

requirements  as  they 

analyses,  changed 

Team  Leader 

evolve  during  the 

individual  and  team 

role  specifi¬ 
cations 

Other  role 
specifications 
as  necessary 

project. 

plans  (either  minor 
replans  or  relaunches) 
WEEK  reports  showing 
Customer  Interface  role 
report  of 

changed/changing 

requirements 

Customer 

REQM  SP 

Maintain  bi-directional 

The  organization  will 

Interface  role 

1.4 

traceability  among  the 

need  to  develop  a  me- 

specification 

requirements  and  work 
products. 

thod  for  maintaining  bi¬ 
directional  traceability. 
Script  REQ  calls  for  the 
establishment  and 
maintenance  of  bi¬ 
directional  traceability 
between  test  plans  and 
SRS,  SRS  and  ERS. 

Customer 

REQM  SP 

Identify  inconsistencies 

When  requirements 

Interface  and 

1.5 

between  the  project 

changes  trigger  replan- 

Planning  role 

plans  and  work  prod- 

ning  and  relaunching, 

specifica- 

ucts  and  the  require- 

inconsistencies  are 

tions,  other 
role  specifi¬ 
cations 

ments. 

documented  and  ad¬ 
dressed  in  the  changed 
plans  (TASK,  SCHED, 
SUMS,  etc.). 

Guidance 


TSP  has  no  standard  exam¬ 
ples  or  specifications  for  the 
SRS,  ERS,  market  study  re¬ 
sults,  and  impact  analysis.  This 
may  be  specific  to  each  instal¬ 
lation — for  example,  feature 
lists,  use  cases,  and  impact 
statements. 

The  SUMS  may  provide  an 
understanding  of  requirements 
but  this  is  not  clear.  There  is  no 
set  of  criteria  in  AIM  for  eva¬ 
luating/accepting  good  re¬ 
quirements. 

During  the  launch,  detailed 
individual  and  team  plans  are 
generated  by  the  team  mem¬ 
bers  for  the  coming  iteration. 
The  launch  process  and  coach 
activities  are  designed  to  en¬ 
sure  that  the  plan  accurately 
relates  to  the  requirements, 
thus  the  launch/relaunch 
creates  very  committed  partici¬ 
pants  (team  and  manage¬ 
ment). 

Same  caveat  as  1 .2  above. 

The  requirements  probably  will 
be  under  formal  configuration 
management.  The  CM 
processes  will  apply. 


The  organization  will  need  to 
develop  a  mechanism  for  bi¬ 
directional  traceability. 

SUMS  and  TASK  may  work  for 
bi-directional  traceability  if 
there  is  a  concerted  effort  dur¬ 
ing  the  launch/relaunch  to  line 
up  the  SUMS  with  require¬ 
ments,  but  this  normally  is  not 
an  ideal  solution.  Bi-directional 
traceability  is  best  accom¬ 
plished  with  a  requirements 
management  tool. 

Same  caveat  as  1 .2  and  1 .3 
above. 
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TSP/PSP  CMMI  CMMI  PA:  REQM 

Reference  Feature  Requirements 

Management 

Direct  Artifact 

Guidance 

REQM 

GG  2 

The  process  is  institu¬ 
tionalized  as  a  ma¬ 
naged  process. 

REQM  GP 
2.1 

Establish  and  maintain  Policy  is  not  addressed 

an  organizational  policy  in  AIM. 
for  planning  and  per¬ 
forming  the  require¬ 
ments  management 
process. 

This  issue  to  be  addressed  by 
the  Implementation  Guide. 

Scripts  REQ, 
ANA,  LAU, 
REL;  form 

INV 

REQM  GP 
2.2 

Establish  and  maintain  Scripts  REQ  and  ANA, 

the  plan  for  performing  and  LAU  and  REL, 

the  requirements  man-  form  INV 

agement  process. 

The  requirements  plan  is  em¬ 
bedded  in  the  launch,  launch 
prep,  and  the  role  of  Customer 
Interface  Manager. 

Scripts 

LAU2,  LAU6, 
TASK;  form 
showing 

REQM  tasks 

REQM  GP 
2.3 

Provide  adequate  re¬ 
sources  for  performing 
the  requirements  man¬ 
agement  process,  de¬ 
veloping  the  work  prod¬ 
ucts,  and  providing  the 
services  of  the  process. 

Customer  interface  role 
plan  from  LAU3,  LAU4, 
and  LAU6,  recorded  in 
TASK  &  SCHEDULE 

Scripts 
PREPL/PRE 
PR,  LAU2; 
form  TEAM 
(showing 
Customer 
Interface 
role) 

REQM  GP 
2.4 

Assign  responsibility 
and  authority  for  per¬ 
forming  the  process, 
developing  the  work 
products,  and  providing 
the  services  of  the  re¬ 
quirements  manage¬ 
ment  process. 

PREPL/PREPR,  LAU2 
role  assignments, 

Team  Leader,  and 
Customer  Interface  role 
RSIM  (Relevant  Stake¬ 
holder  Involvement 
Matrix) 

REQM  GP 
2.5 

Train  the  people  per¬ 
forming  or  supporting 
the  requirements  man¬ 
agement  process  as 
needed. 

Aspects  of  REQM  in 

TSP  training 

OJT  for  Customer  In¬ 
terface  Manager 

After  establishment  of  the  PG 
the  role  of  the  PG  Customer 
Interface  Manager  (CIM)  will 
coordinate  activities  of  the 
team  CIM. 

REQM  GP 
2.6 

Place  designated  work 
products  of  the  re¬ 
quirements  manage¬ 
ment  process  under 
appropriate  levels  of 
control. 

LOGCI  for  SRS  or 
equivalent 

The  Support  Manager 
role  is  responsible  for 

CM  for  the  project.  The 
work  products  from  the 
launch  may  be  CIs  in 
form  LOGCI  and 
placed  under  configura¬ 
tion  control  or  they 
could  be  put  under  less 
formal  control. 

The  project  notebook 
Typically,  you  would 
have  to  look  at  the  CM 
system  supported  by 
the  project  or  organiza¬ 
tion  (a  protected  folder 
on  a  drive,  or  full  CM 
with  CVS). 

Configuration  and  data  man¬ 
agement  are  planned  during 
launch  preparation,  CM 
processes  are  observed  and 
planning  CIs  are  entered  in 
form  LOGCI. 

Filled-in  form 
WEEK  (Cus¬ 
tomer  Inter¬ 
face  role 
report) 

REQM  GP 
2.7 

Identify  and  involve  the 
relevant  stakeholders  of 
the  requirements  man¬ 
agement  process  as 
planned. 

RSIM  (Relevant  Stake¬ 
holder  Involvement 
Matrix)  for  ANA,  SRS 
Customer  Interface 

Role 
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TSP/PSP 

CMMI 

CMMI  PA:  REQM 

Direct  Artifact 

Guidance 

Reference 

Feature 

Requirements 

Management 

Filled-in  form 
WEEK  (Cus¬ 
tomer  Inter¬ 
face  role 
report) 

REQM  GP 
2.8 

Monitor  and  control  the 
requirements  manage¬ 
ment  process  against 
the  plan  for  performing 
the  process  and  take 
appropriate  corrective 
action. 

Filled-in  WEEK  forms 
showing  Customer 
Interface  role  reports, 
replans,  plans  resulting 
from  relaunches. 

The  launch  and  the  weekly 
meetings  form  the  basis  for 
monitoring  the  REQM  activi¬ 
ties. 

TSP  Check¬ 
point 

REQM  GP 
2.9 

Objectively  evaluate 
adherence  of  the  re¬ 
quirements  manage¬ 
ment  process  against 
its  process  description, 
standards,  and  proce¬ 
dures;  address  non- 
compliance. 

Checkpoint  report 

TSP  coach  involvement 
pre-launch 

(PREPL/PREPR  filled 
out),  during  the  launch 
(LAU  meeting  minutes) 
and  after  (LAUPM). 

See  the  role  of  the  PG 
(Process  Group)  Cus¬ 
tomer  Interface  Man¬ 
ager. 

Coaching  Manager 
report 

The  TSP  Coach  will  perform  a 
Checkpoint  to  evaluate 
process  and  work  products 

During  the  launch,  the  coach 
guides  process  fidelity  for 

REQM.  As  the  project  ex¬ 
ecutes,  the  team  leader,  plan¬ 
ning  and  process  managers 
objectively  evaluate. 

When  the  Process  Group  (PG) 
is  formed  the  Coaching  Man¬ 
ager  role  will  objectively  eva¬ 
luate  the  launch  process  and 
artifacts  for  each  launch. 

Specification 

STATUS, 

Quarterly 

Review 

Checklist 

REQM  GP 
2.10 

Review  the  activities, 
status,  and  results  of 
the  requirements  man¬ 
agement  process  with 
higher  level  manage¬ 
ment  and  resolve  is¬ 
sues. 

TASK  plans  that  show 
the  REQM  activities 
should  be  included  in 
the  customer  interface 
role  activities.  These 
can  be  reviewed  with 
upper  management. 

The  STATUS  specification 
does  not  address  review  of 

REQM  activities  explicitly; 
however,  as  a  practical  matter, 
these  activities  are  typically 
included  in  TASK  plans  that 
are  regularly  reviewed. 

Scripts  REQ, 
ANA 

REQM  GP 
3.1 

Establish  and  maintain 
the  description  of  a 
defined  requirements 
management  process. 

The  TSP+  role  of 

Process  Group  Support 
Manager  is  responsible 
for  establishing  and 
maintaining  the  OSSP. 
The  OSSP  will  contain 
the  launch  processes, 
which  are  the  main 
planning  processes. 

The  Launch  Notebook 
(PREPL,  PREPR, 
LAU1-9,  WEEK) 

See  the  PG  Support  Manager 
and  PG  Process  Manager 
roles. 

Project 

NOTEBOOK 

REQM  GP 
3.2 

Collect  work  products, 
measures,  measure¬ 
ment  results,  and  im¬ 
provement  information 
derived  from  planning 
and  performing  the 
requirements  manage¬ 
ment  process  to  support 
the  future  use  and  im¬ 
provement  of  the  organ¬ 
ization’s  processes  and 
process  assets. 

SRSs,  ERSs,  impact 
analyses,  PIPs,  and 
data  contained  in  the 
project  NOTEBOOK 
regarding  requirements 
management  activities 
The  Process  Asset 
Library  and  associated 
collection  mechanisms 
The  organizational 
infrastructure  (including 
the  PAL  and  the  mea¬ 
surement  repository)  is 
developed  by  the 

Process  Group;  see 

OPF,  OPD. 

The  TSP+  has  been  expanded 
to  include  a  PG  Process  Asset 
and  Data  Repository  Manager. 
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3.2.2  Requirements  Development  (RD) 


The  following  table  lists  the  elements  of  the  Requirements  Development  (RD)  process  area  em¬ 
ployed  in  the  AIM  approach. 


TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  RD  Require¬ 
ments  Development 
Description 

Direct  Artifact 

Guidance 

RD  SG 

1 

Stakeholder  needs,  expecta¬ 
tions,  constraints,  and  inter¬ 
faces  are  collected  and  trans¬ 
lated  into  customer 
requirements. 

The  Script  ANA  refer¬ 
ences  ERS  (Enhance¬ 
ment  Requirement 

Study),  MRE  (Market 
Requirements  Elicita¬ 
tion)  and  SRS(System 
Requirements  Specifi¬ 
cation) 

Appropriate  development 
methodolog(ies)  will  need  to 
be  adopted  by  the  organiza¬ 
tion.  These  methodologies 
will  have  their  own  artifacts 
that  may  need  to  be  substi¬ 
tuted  for  those  referenced  in 
the  TSP+. 

Scripts 
REQ  and 
ANA 


RD  SP 
1.1 


Elicit  stakeholder  needs,  ex¬ 
pectations,  constraints,  and 
interfaces  for  all  phases  of  the 
product  life  cycle. 


Market  requirements 
studies,  minutes  and 
other  documentation 
from  elicitation  meet¬ 
ings,  prototypes 


TSP+  stresses  the  need  for 
clear,  understandable  re¬ 
quirements  as  a  basis  for 
planning.  The  specific  activi¬ 
ties  and  artifacts  generated 
will  generally  be  site- 
specific. 

The  launch  meeting  1  prep¬ 
aration  and  script  provide 
for  the  business  objective 
and  the  customer/product 
objective  to  be  given  to  the 
team.  The  team  may  then 
decide  to  plan  for  more 
elicitation  and  validation 
activities  (before/during  or 
after  the  launch) 

The  TSP+  provides  for  the 
Customer  Interface  Manag¬ 
er  role  on  the  TSP+  team. 

Other  locally  defined  forms 
of  captured  requirements 
are  acceptable. 

TSP+  does  not  contain 
standard  formats,  tem¬ 
plates,  or  examples  for 
these  items,  or  detailed 
methods  for  doing  these. 


Scripts 
REQ  and 
ANA 


RD  SP 
1.2 


Transform  stakeholder  needs, 
expectations,  constraints,  and 
interfaces  into  customer  re¬ 
quirements. 


Software  Requirements  Other  locally  defined  forms 

Specifications  (SRS)  of  transformed  requirements 

(e.g.,  according  to  IEEE 
830-1998)  are  acceptable. 
No  standard  format,  tem¬ 
plate,  examples,  or  detailed 
methods  are  given  for  the 


SRS. 

- - 

RD  SG  Customer  requirements  are 

2  refined  and  elaborated  to 

develop  product  and  product- 
component  requirements. 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  RD  Require¬ 
ments  Development 
Description 

Direct  Artifact 

Guidance 

Scripts 

REQ  and 
ANA 

RDSP 

2.1 

Establish  and  maintain  prod¬ 
uct  and  product-component 
requirements,  which  are 
based  on  the  customer  re¬ 
quirements. 

The  TSP+  in  Script  ANA 
produces  an  Impact 
Analysis  Report. 

The  form  and  content  of  the 
Impact  Analysis  Report  is 
not  specified  in  TSP+. 

Same  comment  as  SP1.2. 

This  level  of  the  require¬ 
ments  hierarchy  should  be 
traceable  from  the  lowest  to 
the  highest  levels  (ref 

REQM  SP1.4). 

Script  FILD 

RD  SP 

2.2 

Allocate  the  requirements  for 
each  product  component. 

Impact  Analysis  Report 

The  form  and  content  of  the 
Impact  Analysis  Report  are 
not  specified  in  TSP+. 

Other  locally  defined  forms 
of  allocated  requirements 
(e.g.,  UML)  are  acceptable. 
SUMS  can  be  designed  to 
help. 

No  standard  format,  tem¬ 
plate,  examples,  or  detailed 
methods  are  given  for  allo¬ 
cating  requirements  in  the 
SDS. 

Script  FILD 

RDSP 

2.3 

Identify  interface  require¬ 
ments. 

System  Design  Specifi¬ 
cation  (SDS) 

Same  comment  as  SP2.2. 

No  standard  format,  tem¬ 
plate,  examples,  or  detailed 
methods  are  given  for  iden¬ 
tifying  interface  require¬ 
ments  for  the  SDS. 

RD  SG 

3 

The  requirements  are  ana¬ 
lyzed  and  validated,  and  a 
definition  of  required  functio¬ 
nality  is  developed. 

Operation¬ 
al  Specifi¬ 
cation 
Template 
(PSP) 

Scripts 

REQ  and 
ANA 

RDSP 

3.1 

Establish  and  maintain  opera¬ 
tional  concepts  and  asso¬ 
ciated  scenarios. 

Filled-in  Operational 
Specification  Template 
(OST)  from  PSP,  possi¬ 
bly  part  of  the  Software 
Desiqn  Specification 
(SDS) 

Another  form  of  operational 
scenario  (e.g.,  UML  use 
case)  can  and  often  does 
substitute  for  the  OST. 

Functional 
Specifica¬ 
tion  Tem¬ 
plate 
(PSP) 

RD  SP 

3.2 

Establish  and  maintain  a  defi¬ 
nition  of  required  functionality. 

Filled-in  Functional 
Specification  Template 
(FST),  possibly  part  of 
the  Software  Design 
Specification  (SDS) 
Functional  Design  Spe¬ 
cification  is  from  PSP 

Other  forms  of  functional 
specification  (e.g.,  a  defined 
local  set  of  UML  diagrams) 
can  and  often  do  substitute 
for  the  FST  and  SDS. 

Scripts 

REQ  and 
ANA 

RDSP 

3.3 

Analyze  the  requirements  to 
ensure  that  they  are  neces¬ 
sary  and  sufficient. 

Filled-in  TSP  Inspection 
reports  for  SRS 

ERS,  FST  and  OST  are 
PSP  concepts,  so  there 
may  not  be  defect  log 
entries  from  them. 

“Necessary  and  sufficient” 
are  part  of  the  re¬ 
view/inspection  process. 

TSP+  does  not  provide 
specific  criteria  to  define 
“necessary  and  sufficient.” 
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TSP/PSP 

Reference 

All  LAU 
and  REL 
scripts 


Scripts 
LAU9, 
REQ,  and 
ANA 


CMMI 

Feature 

CMMI  PA:  RD  Require¬ 
ments  Development 
Description 

RD  SP 

Analyze  the  requirements  to 

3.4 

balance  stakeholder  needs 

and  constraints. 

RD  SP  Validate  requirements  to  en- 
3.5  sure  the  resulting  product  will 

perform  as  intended  in  the 
user’s  environment. 


RD  GG  The  process  is  institutiona- 

2  lized  as  a  managed  process. 

RD  GP  Establish  and  maintain  an 

2.1  organizational  policy  for  plan¬ 
ning  and  performing  the  re¬ 
quirements  development 
process. 

RD  GP  Establish  and  maintain  the 

2.2  plan  for  performing  the  re¬ 
quirements  development 
process. 


RD  GP  Provide  adequate  resources 

2.3  for  performing  the  require¬ 
ments  development  process, 
developing  the  work  products, 
and  providing  the  services  of 
the  process. 

RD  GP  Assign  responsibility  and  au- 

2.4  thority  for  performing  the 
process,  developing  the  work 
products,  and  providing  the 
services  of  the  requirements 
development  process. 


Direct  Artifact  Guidance 


Form  GOAL  (document¬ 
ing  management  and 
customer  needs  and 
constraints)  and  all 
alternative  plans  gener¬ 
ated  during  the  launch; 
form  IRTL  in  the  TSP 
Excel  workbook  docu¬ 
menting  issue  and  risks 
associated  with  poten¬ 
tially  conflicting  needs 
and  constraints;  LAU9 
presentation  summariz¬ 
ing  alternative  plans 

This  activity  occurs  repeat¬ 
edly  on  a  project,  and  at  a 
minimum  is  recorded  in  the 
management  presentation 
in  meeting  9  of  the  launch.  If 
no  single  plan  meets  all 
stakeholder  needs  and  con¬ 
straints,  alternative  plans 
are  developed  and  pre¬ 
sented  to  management  at 
that  meeting.  As  a  project 
progresses  and  require¬ 
ments  are  developed  and 
made  specific,  they  interact 
with  other  stakeholder 
needs,  and  constraints  and 
problems  are  resolved  dur¬ 
ing  relaunches. 

The  management  pres¬ 
entation  in  meeting  9 
validates  management 
requirements.  Customer 
requirements  are  vali¬ 
dated  by  developing 
prototypes  and  review¬ 
ing  SRS,  results  of 
elicitation  activities. 

OST,  ERS,  and  SDS 
documents  (artifact  is 
reviewed  defect  logs) 

Specifications  for  SRS, 

ERS,  OST  and  SDS  docu¬ 
ments  should  include  valida¬ 
tion  criteria. 

There  are  no  standard  for¬ 
mats,  templates,  examples, 
or  detailed  implementation 
methods  for  any  of  these 
items. 

Policy  will  be  specific  to 
each  organization. 

Policy  will  be  addressed  by 
the  implementation  guide. 

Scripts  REQ  and  ANA, 
and  LAU  and  REL,  form 
INV 

Launch  preparation  and 
checklist 

Task  plan  for  RD  tasks 

RD  activities  can  be  part  of 
launch  preparation,  as  well 
as  activities  during  the 
launch.  RD  activities  can 
also  be  put  into  the  task 
plans  to  be  performed  dur¬ 
ing  the  cycle. 

Customer  interface  role 
plan  from  LAU3,  LAU4, 
and  LAU6,  recorded  in 
TASK  &  SCHEDULE 

See  the  Customer  Interface 
Manager  role,  senior  man¬ 
agement,  and  product  man¬ 
agement  input  to  meeting  1. 
The  launch  process  and  the 
tasks  and  resources  in  the 

TSP  plan. 

PREPL/PREPR,  LAU2 
role  assignments,  Team 
Leader  and  Customer 
Interface  roles 
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TS  P/PSP 
Reference 


CMMI 

Feature 

RD  GP 
2.5 


RD  GP 
2.6 


RD  GP 
2.7 


RD  GP 
2.8 


RD  GP 
2.9 


CMMI  PA:  RD  Require¬ 
ments  Development 


Place  designated  work  prod¬ 
ucts  of  the  requirements  de¬ 
velopment  process  under 
appropriate  levels  of  control. 


Identify  and  involve  the  rele¬ 
vant  stakeholders  of  the  re¬ 
quirements  development 
process  as  planned. 


Monitor  and  control  the  re¬ 
quirements  development 
process  against  the  plan  for 
performing  the  process  and 
take  appropriate  corrective 
action. 

Objectively  evaluate  adhe¬ 
rence  of  the  requirements 
development  process  against 
its  process  description,  stan¬ 
dards,  and  procedures,  and 
address  noncompliance. 


Direct  Artifact 


On-the-job  training 
provided  to  customer 
interface  role  by  TSP 
Coach  or  Team  Leader 
as  an  adjunct  to  the  role 
description. 

LOGOI  for  SRS  or 
equivalent 

The  Support  Manager 
role  is  responsible  for 
CM  for  the  project.  The 
work  products  from  the 
launch  will  be  CIs  in 
form  LOGCI  and  placed 
under  appropriate  con¬ 
trol. 

The  project  notebook 
Typically,  this  informa¬ 
tion  would  appear  in  the 
CM  system  supported 
by  the  project  or  organi¬ 
zation  (a  protected 
folder  on  a  drive,  or  full 
CM  with  CVS). 

RSIM  (Relevant  Stake¬ 
holder  Involvement 
Matrix)  for  ANA,  SRS 
Role  Assignment  Matrix 
ROLEMX 

Customer  Interface 
Role 

Filled-in  WEEK  forms 
showing  customer  inter¬ 
face  role  reports,  rep¬ 
lans,  plans  resulting 
from  relaunches 

Checkpoint  report 
TSP  Coach  involvement 
pre-launch 

(PREPL/PREPR  filled 
out),  during  the  launch 
(LAU  meeting  minutes), 
and  after  (LAUPM) 


Description 

Train  the  people  performing  or 
supporting  the  requirements 
development  process  as 
needed. 


Guidance 


Elements  of  RD  training  are 
provided  in  Fundamentals 
and  Advanced.  Typical  TSP 
teams  augment  RD/REQM 
processes  with  their  own 
local  knowledge. 


Configuration  and  data 
management  are  planned 
during  launch  preparation, 
CM  processes  are  ob¬ 
served,  and  planning  CIs 
are  entered  in  form  LOGCI 


The  launch  and  the  weekly 
meetings  form  the  basis  for 
monitoring  the  RD  activities. 


The  TSP  Coach  will  perform 
a  Checkpoint  to  evaluate 
process  and  work  products. 
During  the  launch,  the 
Coach  guides  process  fideli¬ 
ty,  including  RD.  As  the 
project  executes,  the  Team 
Leader,  and  Planning  and 
Process  managers  objec¬ 
tively  evaluate. 

When  the  Process  Group 
(PG)  is  formed  the  Coach¬ 
ing  Manager  role  will  objec¬ 
tively  evaluate  the  launch 
process  and  artifacts  for 
each  launch. 
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TSP/PSP 

Reference 


CMMI  CMMI  PA:  RD  Require-  Direct  Artifact  Guidance 

Feature  ments  Development 

Description 


RD  GP 
2.10 


RD  GP 
3.1 


Review  the  activities,  status, 
and  results  of  the  require¬ 
ments  development  process 
with  higher  level  management; 
resolve  issues. 

TASK  plans  that  show 
the  RD  activities  should 
be  included  in  the  Cus¬ 
tomer  Interface  role 
activities.  These  can  be 
reviewed  with  upper 
management. 

The  STATUS  specification 
does  not  address  review  of 
RD  activities  explicitly;  how¬ 
ever  as  a  practical  matter, 
these  activities  are  typically 
included  in  TASK  plans  that 
are  regularly  reviewed. 

Establish  and  maintain  the 
description  of  a  defined  re¬ 
quirements  development 
process. 

The  TSP+  role  of 

Process  Group  Support 
Manager  is  responsible 
for  establishing  and 
maintaining  the  OSSP. 
The  OSSP  will  contain 
the  launch  processes, 
which  are  the  main 
planning  processes. 

The  Launch  Notebook 

See  the  PG  Support  Man¬ 
ager  and  PG  Process  Man¬ 
ager  roles. 

RD  GP 
3.2 


Collect  work  products,  meas¬ 
ures,  measurement  results, 
and  improvement  information 
derived  from  planning  and 
performing  the  requirements 
development  process  to  sup¬ 
port  the  future  use  and  im¬ 
provement  of  the  organiza¬ 
tion’s  processes  and  process 
assets. 


(PREPL,  PREPR, 
LAU1-9,  WEEK) 

SRSs,  ERSs,  impact 
analyses,  PIPs,  and 
data  contained  in  the 
project  NOTEBOOK 
regarding  requirements 
management  activities 
The  Process  Asset 
Library  and  associated 
collection  mechanisms 
The  organizational  in¬ 
frastructure  (including 
the  PAL  and  the  mea¬ 
surement  repository)  is 
developed  by  the 
Process  Group;  see 
OPF,  OPD. 


The  TSP+  has  been  ex¬ 
panded  to  include  a  PG 
Process  Asset  and  Data 
Repository  Manager. 
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3.2.3  Technical  Solution  (TS) 


The  following  table  lists  the  elements  of  the  Technical  Solution  (TS)  process  area  employed  in  the 
AIM  approach. 


TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  TS 

Technical  Solution 

Direct  Artifact 

Guidance 

TS  SG  1 

Product  or  product- 
component  solutions  are 
selected  from  alternative 
solutions. 

Appropriate  development  me¬ 
thodologies)  will  need  to  be 
adopted  by  the  organization. 
These  methodologies  will  have 
their  own  artifacts  that  will 
need  to  be  substituted  for 
those  referenced  in  the  TSP+. 

Design 

Manager 

role 

TS  SP 

1.1 

Develop  alternative  solu¬ 
tions  and  selection  criteria. 

The  DAR  script  and  form 
can  be  used  in  docu¬ 
menting  the  alternative 
solutions  and  selection 
criteria. 

The  Design  Manager  should 
ensure  that  alternative  solu¬ 
tions  are  developed  as  appro¬ 
priate.  DAR  activities  should 
be  planned  for  and  tracked  in 
the  team’s  plan. 

Design 

Manager 

role 

TS  SP 

1.2 

Select  the  product- 
component  solutions  that 
best  satisfy  the  criteria 
established. 

The  DAR  script  and  form 
can  be  used  to  identify 
the  solution  that  best 
satisfies  the  established 
criteria. 

Tasks  showing  the  plan 
and  actual  for  implement¬ 
ing  the  best  solution 

See  Current  scripts  REQ, 

ANA,  and  HLD  that  call  for 
documenting  the  design  in  the 
ERS  and/or  SRS.  DAR  forms 
should  be  used  to  capture  the 
reasoning  behind  solution 
selection. 

TS  SG  2 

Product  or  product  com¬ 
ponent  designs  are  devel¬ 
oped. 

Scripts 

HLD,  IMP 
Design 
Manager 
role 

TS  SP 

2.1 

Develop  a  design  for  the 
product  or  product  compo¬ 
nent. 

Engineering  Require¬ 
ments  Specification 
(ERS) 

Software  Design  Specifi¬ 
cation  (SDS) 

PSP  design  templates 

Each  organization  must  decide 
on  design  methodology  with 
associated  tools  and  artifacts. 
While  the  Design  Manager  role 
has  explicit  responsibility  for 
design  standards  and  proce¬ 
dures  for  the  team,  there  is  no 
guidance  for  these  (the  weak¬ 
nesses),  with  the  low-level 
exception  of  the  PSP  design 
templates. 

No  standard  format,  template, 
examples,  or  detailed  methods 
are  given  for  the  ERS  or  SDS. 

Scripts 

HLD,  IMP 
Design 
manager 
role 

TS  SP 

2.2 

Establish  and  maintain  a 
technical  data  package. 

ERS,  SDS 

PSP  design  templates 

Each  organization  must  decide 
on  design  methodologies  and 
artifacts  for  the  technical  data 
package.  The  Design  Manager 
role  will  take  the  lead. 

The  collection  of  filled-in  tem¬ 
plates  at  the  appropriate  level 
of  the  design  comprises  the 
technical  data  package.  Above 
the  level  of  the  PSP  design 
templates,  there  is  no  similarly 
detailed  guidance. 

No  standard  format,  template, 
examples,  or  detailed  methods 
are  given  for  the  ERS  or  SDS. 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  TS 

Technical  Solution 

Direct  Artifact 

Guidance 

Script  HLD 

TS  SP 

2.3 

Design  product- 
component  interfaces 
using  established  criteria. 

ERS 

Each  organization  must  decide 
on  design  methodologies. 

Script  HLD  calls  for  document¬ 
ing  “(hardware-)  software- 
system  interfaces”  in  the  ERS, 
but  there  is  no  other  guidance 
for  capturing  interfaces  or 
establishing  criteria  for  their 
design. 

No  standard  format,  template, 
examples,  or  detailed  methods 
are  given  for  the  ERS. 

Support 

Manager 

role 

TS  SP 

2.4 

Evaluate  whether  the 
product  components 
should  be  developed, 
purchased,  or  reused 
based  on  established 
criteria. 

The  DAR  script  and  form 
can  be  used  to  document 
the  evaluation  criteria 
and  resulting  decision  of 
whether  the  product 
components  should  be 
developed,  purchased,  or 
reused.  This  may  also  be 
addressed  as  part  of  the 
launch  process,  and  thus 
captured  in  the  STRAT 
and  INV  forms. 

The  Support  Manager  has 
explicit  responsibility  for  advo¬ 
cating  reuse,  but  there  is  no 
other  guidance  in  this  area. 

The  DAR  process  should  be 
used  to  evaluate  the  decision 
on  whether  to  develop,  pur¬ 
chase,  or  reuse  components. 
This  is  partly  addressed  by  the 
team’s  strategy  developed 
during  launch  meeting  3.  De¬ 
pending  on  the  development 
phase  and  the  nature  of  the 
component,  the  responsibility 
associated  with  this  evaluation 
could  fall  on  either  the  support, 
design,  or  implementation 
managers. 

TS  SG  3 

Product  components,  and 
associated  support  docu¬ 
mentation,  are  imple¬ 
mented  from  their  designs. 

Script 

HLD,  IMP 
Implemen¬ 
tation 
Manager 
role 

TS  SP 

3.1 

Implement  the  designs  of 
the  product  components. 

Detailed  designs  (from 
higher  levels  of  the  prod¬ 
uct  hierarchy),  code  (at 
the  lowest  levels),  review 
logs,  test  cases,  test 
results 

There  are  no  real  problems 
here  unless  no  design  is  pro¬ 
duced,  or  a  design  is  produced 
and  the  implementation  fails  to 
follow  it. 

Scripts 

DEV, 

ANA,  and 

MAINT 

Script 

LAU3 

TS  SP 

3.2 

Develop  and  maintain  the 
end-user  documentation. 

Preliminary  User  Manual 
(DEV),  or  changes  to 
same  (ANA  and  MAINT) 
Forms  SUMS,  TASK, 
LOGT,  LOGD  (entries  for 
installation,  user,  and 
maintenance  manuals) 
and  final  outputs  from 
these  activities 

While  there  is  no  specific  guid¬ 
ance  in  the  scripts  for  develop¬ 
ing  and  maintaining  documen¬ 
tation,  the  TSP  plans  and  the 
final  results  will  speak  for 
themselves.  Documentation 
will  show  up  in  SUMS  and 
tasks  in  the  individual  and 
team  workbooks. 

TS  GG 

2 

The  process  is  institutiona¬ 
lized  as  a  managed 
process. 

TS  GP 

2.1 

Establish  and  maintain  an 
organizational  policy  for 
planning  and  performing 
the  technical  solution 
process. 

Policy  is  not  addressed  in 
AIM. 

This  issue  to  be  addressed  by 
the  Implementation  Guide. 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  TS 

Technical  Solution 

Direct  Artifact 

Guidance 

TS  GP 

2.2 

Establish  and  maintain  the 
plan  for  performing  the 
technical  solution  process. 

Scripts  FILD  and  IMP, 
and  LAU  and  REL,  form 
SUMS 

See  the  Design  Manager  role 
activities  and  plan. 

TS  GP 

2.3 

Provide  adequate  re¬ 
sources  for  performing  the 
technical  solution  process, 
developing  the  work  prod¬ 
ucts,  and  providing  the 
services  of  the  process. 

Design  Manager  role 
plan  from  LAU3,  LAU4, 
and  LAU6,  recorded  in 
TASK  and  SCHEDULE 

Design  activities  during  the 
launch  and  tasks  in  the  plan. 

TS  GP 

2.4 

Assign  responsibility  and 
authority  for  performing 
the  process,  developing 
the  work  products,  and 
providing  the  services  of 
the  technical  solution 
process. 

PREPL/PREPR,  LAU2 
role  assignments,  Team 
Leader,  and  Design 
Manager  roles 

See  the  Design  Manager  role. 

TS  GP 

2.5 

Train  the  people  perform¬ 
ing  or  supporting  the  tech¬ 
nical  solution  process  as 
needed. 

PSP  training,  as  well  as 
on-the-job  training  pro¬ 
vided  to  Design  Manager 
role  by  TSP  Coach  or 

Team  Leader  as  an  ad¬ 
junct  to  the  role  descrip¬ 
tion 

Design  templates  from  PSP 
training  map  fairly  well  to  com¬ 
ponent-level  technical  solution 
requirements.  Typical  TSP 
teams  augment  HLD  and  IPM 
processes  with  their  own  local 
knowledge. 

There  is  no  guidance  or  refer¬ 
ence  on  alternative  solutions  or 
evaluation  criteria. 

TS  GP 

2.6 

Place  designated  work 
products  of  the  technical 
solution  process  under 
appropriate  levels  of  con¬ 
trol. 

LOGCI  for  SRS  or  equiv¬ 
alent 

The  Support  Manager 
role  is  responsible  for  CM 
for  the  project.  The  work 
products  from  the  launch 
will  be  CIs  in  form  LOGCI 
and  placed  under  appro¬ 
priate  control.  Other  arti¬ 
facts  will  be  placed  under 
informal  control. 

The  project  notebook 
Typically,  this  information 
would  appear  in  the  CM 
system  supported  by  the 
project  or  organization  (a 
protected  folder  on  a 
drive,  or  full  CM  with 

CVS). 

Configuration  and  data  man¬ 
agement  are  planned  during 
launch  preparation.  CM 
processes  are  observed  and 
planning  CIs  are  entered  in 
form  LOGCI. 

Design 

Manager 

role 

TS  GP 

2.7 

Identify  and  involve  the 
relevant  stakeholders  of 
the  technical  solution 
process  as  planned. 

RSIM  (Relevant  Stake¬ 
holder  Involvement  Ma¬ 
trix)  for  ANA,  SRS 

Role  Assignment  Matrix 
ROLEMX 

Customer  Interface  role,  De¬ 
sign  Manager,  and  possibly  the 
Team  Leader  interact  with 
design  stakeholders  and  report 
to  the  team  weekly  (and  fill  in 
WEEK  forms). 

TS  GP 

2.8 

Monitor  and  control  the 
technical  solution  process 
against  the  plan  for  per¬ 
forming  the  process;  and 
take  appropriate  corrective 
action. 

Filled-in  WEEK  forms 
showing  Design  Manager 
role  reports,  replans,  and 
plans  resulting  from  re¬ 
launches 
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TSP/PSP 

Reference 


CMMI  CMMI  PA:  TS  Direct  Artifact  Guidance 

Feature  Technical  Solution 


TS  GP 
2.9 


Objectively  evaluate  adhe¬ 
rence  of  the  technical 
solution  process  against 
its  process  description, 
standards,  and  proce¬ 
dures;  address  noncom¬ 
pliance. 


TS  GP 
2.10 


TS  GP 
3.1 


TS  GP 
3.2 


Review  the  activities,  sta¬ 
tus,  and  results  of  the 
technical  solution  process 
with  higher  level  manage¬ 
ment  ;resolve  issues. 


Collect  work  products, 
measures,  measurement 
results,  and  improvement 
information  derived  from 
planning  and  performing 
the  technical  solution 
process  to  support  the 
future  use  and  improve¬ 
ment  of  the  organization’s 
processes  and  process 
assets. 


Checkpoint  report 
TSP  Coach  involvement 
pre-launch 

(PREPL/PREPR  filled 
out),  during  the  launch 
(LAU  meeting  minutes) 
and  after  (LAUPM) 


Establish  and  maintain  the 
description  of  a  defined 
technical  solution  process. 


TASK  plans  that  show 
the  TS  activities  should 
be  included  in  the  Design 
Manager  role  activities. 
These  can  be  reviewed 
with  upper  management. 

The  TSP+  role  of 
Process  Group  Support 
Manager  is  responsible 
for  establishing  and 
maintaining  the  OSSP. 
The  OSSP  will  contain 
the  launch  processes, 
which  are  the  main  plan¬ 
ning  processes. 

The  Launch  Notebook 
(PREPL,  PREPR,  LAU1- 
9,  WEEK) 

SRSs,  ERSs,  impact 
analyses,  PIPs,  and  data 
contained  in  the  project 
NOTEBOOK  regarding 
requirements  manage¬ 
ment  activities 
The  Process  Asset  Li¬ 
brary  and  associated 
collection  mechanisms 
The  organizational  infra¬ 
structure  (including  the 
PAL  and  the  measure¬ 
ment  repository)  is  de¬ 
veloped  by  the  Process 
Group;  see  OPF,  OPD. 


The  TSP  Coach  will  perform  a 
Checkpoint  to  evaluate 
process  and  work  products. 
During  the  launch,  the  Coach 
guides  process  fidelity  includ¬ 
ing  TS.  As  the  project  ex¬ 
ecutes,  the  Team  Leader,  and 
Planning  and  Process  Manag¬ 
ers  objectively  evaluate. 

When  the  Process  Group  (PG) 
is  formed  the  Coaching  Man¬ 
ager  role  will  objectively  eva¬ 
luate  the  launch  process  and 
artifacts  for  each  launch. 

The  STATUS  specification 
does  not  address  review  of  TS 
activities  explicitly;  however  as 
a  practical  matter,  TS  activities 
are  typically  included  in  TASK 
plans  that  are  regularly  re¬ 
viewed. 

See  the  PG  Support  Manager 
and  PG  Process  Manager 
roles. 


The  TSP+  has  been  expanded 
to  include  a  PG  Process  Asset 
and  Data  Repository  Manager. 
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3.2.4  Product  Integration  (PI) 


The  following  table  lists  the  elements  of  the  Product  Integration  (PI)  process  area  employed  in  the 
AIM  approach. 


TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  PI 

Product  Integration 

Direct  Artifact 

Guidance 

PI  SG  1 

Preparation  for  product 
integration  is  conducted. 

Appropriate  development 
methodolog(ies)  will  need  to 
be  adopted  by  the  organiza¬ 
tion.  These  methodologies 
will  have  their  own  artifacts 
that  may  need  to  be  substi¬ 
tuted  for  those  referenced 
in  the  TSP+  and  this  docu¬ 
ment. 

Script  HLD, 
TEST, 

TEST2 

Test  man¬ 
ager  role 

PI  SP  1.1 

Determine  the  product- 
component  integration  se¬ 
quence. 

Integration  plan  as  de¬ 
scribed  in  TEST2 

No  template  for  the  integra¬ 
tion  plan  is  provided. 

Script  LAU3 

PI  SP  1.2 

Establish  and  maintain  the 
environment  needed  to 
support  the  integration  of 
the  product  components. 

Scripts  LAU3  and 

TEST2,  and  the  Support 
Manager  role  descrip¬ 
tion. 

Site  specific  artifacts 
regarding  environment 

The  Support  Manager  role 
should  have  responsibility 
for  ensuring  that  an  ade¬ 
quate  integration  environ¬ 
ment  is  available  when 
needed.  Scripts  LAU3  and 
TEST2,  and  the  Support 
Manager  role  description, 
should  describe  explicitly 
the  integration  environment. 
While  the  integration  envi¬ 
ronment  is  not  called  out 
explicitly,  it  is  necessary  to 
the  project  and  will  be  ad¬ 
dressed  by  the  Test  Man¬ 
ager  role  and  the  Support 
Manager  role. 

Script  HLD, 
TEST, 

TEST2 

Test  Man¬ 
ager  role 

PI  SP  1.3 

Establish  and  maintain  pro¬ 
cedures  and  criteria  for 
integration  of  the  product 
components. 

Integration  plan  as  de¬ 
scribed  in  TEST2 

No  template  is  provided. 

PI  SG  2 

The  product  component 
interfaces,  both  internal  and 
external,  are  compatible. 

Script  HLD, 
TEST, 

TEST2 

Test  Man¬ 
ager  role 

PI  SP  2.1 

Review  interface  descrip¬ 
tions  for  coverage  and 
completeness. 

Results  of  integration 
plan  review  as  described 
in  Script  TEST2 

Interfaces  specifically 
addressed  in  TEST2 
step  2  in  the  integration 
plan 

Refer  to  TS  SP  2.3,  which 
calls  for  creation  of  inter¬ 
face  descriptions.  The  ex¬ 
pectation  is  that  interfaces 
are  described  and  invento¬ 
ried. 

No  template  is  provided. 
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TSP/PSP 

Reference 

Scripts 
REQ,  HLD, 
TEST2 


Scripts 

IMP6, 

TEST, 

TEST1, 

TEST2 

Form 

TESTLOG 


CMMI  CMMI  PA:  PI 

Feature  Product  Integration 

PI  SP  2.2  Manage  internal  and  exter¬ 

nal  interface  definitions, 
designs,  and  changes  for 
products  and  product  com¬ 
ponents. 


PI  SG  3  Verified  product  compo¬ 
nents  are  assembled  and 
the  integrated,  verified,  and 
validated  product  is  deli¬ 
vered. 

PI  SP  3.1  Confirm,  prior  to  assembly, 
that  each  product  compo¬ 
nent  required  to  assemble 
the  product  has  been  prop¬ 
erly  identified  and  functions 
according  to  its  description, 
and  that  the  product- 
component  interfaces 
comply  with  the  interface 
descriptions. 


Direct  Artifact  Guidance 

Engineering  Require-  The  organization  will  need 

ments  Specification  to  make  a  decision  about 

(ERS)  which  design  methodolo¬ 

gies  to  employ. 

The  handling  of  interfaces 
should  be  made  concise, 
with  clear  identification  of 
artifacts  in  order  to  estab¬ 
lish  clear  CMMI  com¬ 
pliance. 

Currently,  no  template, 
specification,  or  criteria  for 
the  ERS  and  SDS  are  in 
TSP+.  Also,  there  is  no 
particular  direction  for  han¬ 
dling  interface  changes,  nor 
is  there  any  way  to  know 
(e.g.,  through  an  index  or 
inventory)  what  all  the  inter¬ 
faces  are  or  where  they 
reside. 


Filled-in  TESTLOG 
showing  unit  and  build 
tests  run,  defect  logs 
showing  component 
defects  in  UT  or  earlier, 
time  logs  of  relevant 
activities  (especially 
IMP6  activities),  PSP 
test  reports,  the  Integra¬ 
tion  Test  Package 


The  organization  must 
adopt  appropriate  metho¬ 
dologies  here. 

The  TSP+  has  the  following 
that  may  be  used  as  a  par¬ 
tial  solution: 

INS  script,  especially  in  the 
Inspection  Briefing,  could 
list  interfaces  as  a  focus 
area  of  a  design  inspection. 
TSP  scripts  do  not  explicitly 
require  PSP  Test  Reports 
(in  IMP6)  or  the  PSP  design 
templates  (in  IMP)  that 
would  completely  specify 
functions  and  interfaces, 
and  confirmations  thereof. 
These  artifacts  are  likely  to 
be  weak  in  this  area,  as 
there  are  no  clear  direct 
artifacts,  especially  regard¬ 
ing  interfaces. 

The  Integration  Test  Pack¬ 
age  (TEST2)  is  not  well 
defined. 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  PI 

Product  Integration 

Direct  Artifact 

Guidance 

Script 

TEST2 

PI  SP  3.2 

Assemble  product  compo¬ 
nents  according  to  the 
product  integration  se¬ 
quence  and  available  pro¬ 
cedures. 

Integration  Plan,  Integra¬ 
tion  Test  Package 

The  organization  must  fol¬ 
low  its  procedures  and 
methodology. 

The  TSP+  provides  a  partial 
solution,  however,  again, 

there  is  a  need  for  tem¬ 
plates  for  these  artifacts. 
Neither  the  Integration  Plan 
nor  the  Integration  Test 
Package,  referenced  in 
script  TEST2,  are  well  de¬ 
fined. 


Script 

IMP6, 

TEST2 


Scripts 

TEST1, 

TEST2, 

TEST3 


PI  SP  3.3  Evaluate  assembled  prod¬ 
uct  components  for  inter¬ 
face  compatibility. 


Integration  Plan,  Integra-  The  organization  must 
tion  Test  Package  adopt  appropriate  metho¬ 

dologies  here. 

The  TSP+  may  provide  a 
partial  solution,  however, 
again,  there  is  a  need  for 
templates.  Also,  IMP6  spe¬ 
cifies  an  interface  test,  but 
there  is  no  clear  guidance 
for  structuring  or  recording 
test  results. 

These  artifacts  are  likely  to 
be  weak  in  this  area,  as 
there  are  no  clear  direct 
artifacts,  especially  regard¬ 
ing  interfaces.  Neither  the 
Integration  Plan  nor  the 
Integration  Test  Package, 
referenced  in  script  TEST2, 
are  well  defined. 


PI  SP  3.4 


Package  the  assembled 
product  or  product  compo¬ 
nent  and  deliver  it  to  the 
appropriate  customer. 


PI  GG  3 


The  process  is  institutiona¬ 
lized  as  a  defined  process. 


Built,  integrated,  or  sys¬ 
tem-tested  product  or 
components  in  the  confi¬ 
guration  management 
system 

Time  and  Defect  Logs 
showing  that  the  TEST 
scripts  have  been  ex¬ 
ecuted 


This  could  be  implemented 
differently  on  every  project 
and  in  every  organization. 
No  specific  criteria  currently 
exist  for  customer  delivery. 


PIGP2.1  Establish  and  maintain  an  No  policies  in  TSP 
organizational  policy  for 
planning  and  performing  the 
product  integration  process. 


PI  GP  2.2 


Establish  and  maintain  the 
plan  for  performing  the 
product  integration  process. 


Script  TEST2,  form 
SUMS,  form  TASK 


The  Implementation  Guide 
will  help  address  this. 


PI  activities  should  be  tasks 
in  the  plan. 


PI  GP  2.3 


Provide  adequate  resources 
for  performing  the  product 
integration  process,  devel¬ 
oping  the  work  products, 
and  providing  the  services 
of  the  process. 


Specific  tasks  in  individ¬ 
ual  and  consolidated 
work  plans  from  LAU3, 
LAU4,  and  LAU6,  rec¬ 
orded  in  TASK  & 
SCHEDULE 


PI  activities  and  resources 
will  be  in  the  individual, 
team,  and  role  plans,  in¬ 
cluding  the  Test  Manager 
and  Support  Manager  roles. 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  PI 

Product  Integration 

Direct  Artifact 

Guidance 

PI  GP  2.4 

Assign  responsibility  and 
authority  for  performing  the 
process,  developing  the 
work  products,  and  provid¬ 
ing  the  services  of  the  prod¬ 
uct  integration  process. 

PREPL/PREPR,  LAU2 
role  assignments,  Team 
Leader  and  Test,  De¬ 
sign,  and  Implementa¬ 
tion  roles 

See  the  team  leader  and 
test,  design,  and  implemen¬ 
tation  roles. 

PI  GP  2.5 

Train  the  people  performing 
or  supporting  the  product 
integration  process  as 
needed. 

PSP  training,  as  well  as 
on-the-job  training,  pro¬ 
vided  to  role  managers 
for  product  integration  by 
TSP  Coach  or  Team 
Leader  as  an  adjunct  to 
the  role  description 

There  is  no  guidance  or 
reference  on  specific  train¬ 
ing  in  integration  practices. 

PI  GP  2.6 

Place  designated  work 
products  of  the  product 
integration  process  under 
appropriate  levels  of  control. 

LOGCI  for  integration 
work  products 

The  Support  Manager 
role  is  responsible  for 

CM  for  the  project.  The 
work  products  from  the 
launch  will  be  CIs  in  form 
LOGCI  and  placed  under 
appropriate  control.  Oth¬ 
er  artifacts  will  be  placed 
under  informal  control. 

The  project  notebook 
Typically,  this  informa¬ 
tion  would  appear  in  the 
CM  system  supported  by 
the  project  or  organiza¬ 
tion  (a  protected  folder 
on  a  drive,  or  full  CM 
with  CVS). 

Configuration  and  data 
management  are  planned 
during  launch  preparation. 

CM  processes  are  ob¬ 
served  and  planning  CIs 
are  entered  in  form  LOGCI. 

Relevant 
role  man¬ 
agers  (De¬ 
sign,  Test, 
Implemen¬ 
tation) 

See  PIP 
ALL-2. 

PI  GP  2.7 

Identify  and  involve  the 
relevant  stakeholders  of  the 
product  integration  process 
as  planned. 

RSIM  (Relevant  Stake¬ 
holder  Involvement  Ma¬ 
trix)  for  ANA,  SRS,  other 
appropriate  work  prod¬ 
ucts 

Role  Assignment  Matrix 
ROLEMX 

The  Customer  Interface 
role,  Design  Manager,  Test 
Manager,  and  possibly  the 
team  leader  interact  with 
stakeholders  and  report  to 
the  team  weekly  (filled-in 
WEEK  forms). 

PI  GP  2.8 

Monitor  and  control  the 
product  integration  process 
against  the  plan  for  perform¬ 
ing  the  process  and  take 
appropriate  corrective  ac¬ 
tion. 

Filled-in  WEEK  forms 
showing  role  reports  and 
integration  tasks,  rep¬ 
lans,  and  plans  resulting 
from  relaunches 
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TSP/PSP 

Reference 


CMMI  CM  Ml  PA:  PI  Direct  Artifact 


Feature  Product  Integration 


PI  GP  2.9  Objectively  evaluate  adhe¬ 
rence  of  the  product  integra¬ 
tion  process  against  its 
process  description,  stan¬ 
dards,  and  procedures; 
address  noncompliance. 


Checkpoint  report 
TSP  Coach  involvement 
pre-launch 

(PREPL/PREPR  filled 
out),  during  the  launch 
(LAU  meeting  minutes) 
and  after  (LAUPM) 


PI  GP 
2.10 


PI  GP  3. 


Review  the  activities,  status, 
and  results  of  the  product 
integration  process  with 
higher  level  management ; 
resolve  issues. 


TASK  plans  that  show 
the  PI  activities  included 
in  various  role  and  team 
member  activities.  These 
can  be  reviewed  with 
upper  management. 


1  Establish  and  maintain  the 
description  of  a  defined 
product  integration  process. 


The  TSP+  role  of 
Process  Group  Support 
Manager  is  responsible 
for  establishing  and 
maintaining  the  OSSP. 
The  OSSP  will  contain 
the  processes,  scripts, 
and  forms. 


The  Launch  Notebook 


(PREPL,  PREPR,  LAU1- 
9,  WEEK) 


PI  GP  3.2  Collect  work  products, 

measures,  measurement 
results,  and  improvement 
information  derived  from 
planning  and  performing  the 
product  integration  process 
to  support  the  future  use 
and  improvement  of  the 
organization’s  processes 
and  process  assets. 


Actual  integration  plans, 
PIPs,  and  data  con¬ 
tained  in  the  project 
NOTEBOOK  regarding 
integration  activities 
SRSs,  ERSs,  impact 
analyses,  PIPs,  and  data 
contained  in  the  project 
NOTEBOOK  regarding 
requirements  manage¬ 
ment  activities 


The  Process  Asset  Li¬ 
brary  and  associated 
collection  mechanisms 


The  organizational  infra¬ 
structure  (including  the 
PAL  and  the  measure¬ 
ment  repository)  is  de¬ 
veloped  by  the  Process 
Group;  see  OPF,  OPD. 


Guidance 

The  TSP  Coach  will  per¬ 
form  a  Checkpoint  to  eva¬ 
luate  process  and  work 
products. 

During  the  launch,  the 
Coach  guides  process  fidel¬ 
ity,  including  PI.  As  the 
project  executes,  the  Team 
Leader  and  Planning  and 
Process  Managers  objec¬ 
tively  evaluate. 

When  the  Process  Group 
(PG)  is  formed  the  Coach¬ 
ing  Manager  role  will  objec¬ 
tively  evaluate  the  launch 
process  and  artifacts  for 
each  launch. 

The  STATUS  specification 
does  not  address  review  of 
PI  activities  explicitly;  how¬ 
ever,  as  a  practical  matter, 
PI  activities  are  typically 
included  in  TASK  plans  that 
are  regularly  reviewed. 

See  the  PG  Support  Man¬ 
ager  and  PG  Process  Man¬ 
ager  roles. 


The  TSP+  has  been  ex¬ 
panded  to  include  a  PG 
Process  Asset  and  Data 
Repository  Manager. 
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3.2.5  Verification  (VER) 


The  following  table  lists  the  elements  of  the  Verification  (VER)  process  area  employed  in  the 
AIM  approach. 


PSP/TSP 

CMMI 

CMMI  PA:  VER 

Direct  Artifact 

Guidance 

Reference 

Feature 

Verification 

Description 

VER  SG  1  Preparation  for  Appropriate  development  me- 

verification  is  thodolog(ies)  will  need  to  be 

conducted.  adopted  by  the  organization. 

These  methodologies  will  have 
their  own  artifacts  that  will  need 
to  be  substituted  for  those  refe¬ 
renced  in  the  TSP+.  The  engi¬ 
neering  process  areas  will  gen¬ 
erally  be  a  hybrid  of  those  in 
AIM  and  the  appropriate  me¬ 
thods  for  the  domain  and  the 
project. 


Scripts  REQ,  VER  SP 
HLD,  IMP,  1.1 
IMIP6 


Select  the  work 
products  to  be 
verified  and  the 
verification  me¬ 
thods  that  will  be 
used  for  each. 


Filled-in  TASK  plans  showing 
review,  inspection,  and/or 
test  activities  for  each  specif¬ 
ic  work  product 
Also  in  test  plans,  system 
test  plan,  integration  test 
plan,  and  acceptance  test 
plan  where  appropriate 


AIM  and  TSP+  take  a  very 
rigorous  approach  to  verifica¬ 
tion.  While  there  may  appear  to 
be  no  distinct  selection  process 
to  determine  which  work  prod¬ 
ucts  are  subjected  to  which 
verification  methods,  the  selec¬ 
tion  is  embedded  with  the 
choice  of  processes  (scripts) 
applied  to  each  work  product. 
Verification  and/or  test  activities 
are  part  of  the  process.  The 
selection  of  work  products  and 
methods  are  developed  by  the 
team,  with  the  Coach,  Process 
Manager,  and  Quality  Manager. 
Work  products  (e.g.,  SRS, 

ERS,  SDS,  components,  and 
test  and  integration  plans)  and 
their  associated  defined 
processes  specify  the  types  of 
verification  methods  applied  to 
each.  The  verification  activities 
then  become  tasks  in  an  indi¬ 
vidual’s  TASK  list.  Note:  The 
TSP  Excel  tool  autofilter  can 
create  a  list  of  all  TASK  plan 
entries  of  a  given  type  (e.g., 
review,  inspection,  test). 


Script  LAU3,  VER  SP 

Test  and  1.2 

Support 
Manager  role 
specifications 


Establish  and 
maintain  the 
environment 
needed  to  sup¬ 
port  verification. 


Filled-in  form  INV  as  called 
for  in  LAU3  steps  8  (devel¬ 
opment  tools  and  facilities); 
individuals’  TASK  plans  and 
LOGT  entries  related  to  this; 
test  plans  that  document  the 
environment 


The  test  and  support  roles  have 
responsibility  for  specifying  and 
building/obtaining  the  verifica¬ 
tion  environment  as  part  of  the 
overall  development  environ¬ 
ment  (which  is  explicitly  called 
out). 

There  is  no  explicit  direction  for 
establishing  the  verification 
environment  in  the  test  scripts. 
Look  to  the  Quality  and  Support 
Manager  roles  and  responsibili¬ 
ties. 
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PSP/TSP 

CMMI 

CMMI  PA:  VER 

Direct  Artifact 

Guidance 

Reference 

Feature 

Verification 

Description 

Scripts 

TESTx, 

REQ,  HLD, 
IMP,  IMP6 

VER  SP 

1.3 

Establish  and 
maintain  verifi¬ 
cation  proce¬ 
dures  and  crite¬ 
ria  for  the 
selected  work 
products. 

Unit  test  plans,  build  plans, 
integration  plans,  system  test 
plan 

The  scripts  provide  directives 
for  establishing  verification 
procedures  and  criteria.  How¬ 
ever,  template  or  detailed  crite¬ 
ria  for  build,  integration,  and 
system  test  plans  are  not  pro¬ 
vided.  The  organization  and 

Coach  will  need  to  augment 
what  is  in  TSP+. 

Quality  Man¬ 
ager  role 
specification 

VER  SG  2 

Peer  reviews 
are  performed 
on  selected 
work  products. 

Individual  and  team  plans 
include  tasks  for  peer  re¬ 
views. 

The  TSP  quality  manager  role 
has  explicit  responsibility  to 
prepare,  conduct,  and  perform 
data  analysis  of  peer  reviews 
(script  and  form  INS). 

Scripts 

LAU5,  INS 
Quality  Man¬ 
ager  role 
specification 

VER  SP 

2.1 

Prepare  for  peer 
reviews  of  se¬ 
lected  work 
products. 

SUMP  and  SUMQ  (plans 
and  actuals  for  inspection 
yields,  defects,  defect  densi¬ 
ties);  inspection  preparation 
activities  reflected  in  TASK 
plans,  LOGT  entries 

LAU5  produces  the  quality  plan 
(SUMP  and  SUMQ),  which 
plans  and  later  tracks  the  ex¬ 
ecution  and  effectiveness  of  all 
similar  (REQ,  HLD,  DLD, 

CODE)  reviews.  The  first  three 
steps  of  script  INS  are  prepara¬ 
tion. 

Script  INS 
Quality  Man¬ 
ager  role 
specification 

VER  SP 

2.2 

Conduct  peer 
reviews  on  se¬ 
lected  work 
products  and 
identify  issues 
resulting  from 
the  peer  review. 

Filled-in  INS  forms;  TASK 
plans,  LOGT  and  LOGD 
entries  related  to  these  ac¬ 
tivities 

Reviews  and  inspections  along 
with  results  are  a  very  impor¬ 
tant  component  to  the  perfor¬ 
mance  of  TSP+. 

Scripts  INS, 

PM 

Quality  Man¬ 
ager  role 
specification 

VER  SP 

2.3 

Analyze  data 
about  prepara¬ 
tion,  conduct, 
and  results  of 
the  peer  re¬ 
views. 

Filled-in  INS  forms,  specifi¬ 
cally  capture/recapture  cal¬ 
culations;  SUMP/SUMQ 
quality  data;  PM  results  deal¬ 
ing  with  inspection  effective¬ 
ness;  filled-in  WEEK  form 
with  Quality  Manager  report 
on  previous  week’s  inspec¬ 
tion  activities. 

TSP+  provides  postmortem 
structure  for  analyzing  conduct 
and  results. 

VER  SG  3 

Selected  work 
products  are 
verified  against 
their  specified 
requirements. 

Scripts 

TESTx, 

REQ,  HLD, 
IMP,  IMP6 

Form 

TESTLOG 
Quality  and 
Test  Manag¬ 
er  role  speci¬ 
fications 

VER  SP 

3.1 

Perform  verifica¬ 
tion  on  the  se¬ 
lected  work 
products. 

Filled-in  TESTLOG,  unit  test 
results,  build  results,  integra¬ 
tion  results,  system  test  re¬ 
sults;  LOGT  and  LOGD  en¬ 
tries  resulting  from  these 
activities 

There  is  no  standard  TSP+ 
template  or  format  for  test  re¬ 
sults  beyond  the  TESTLOG. 

Script  PM 
Quality  and 
Test  Manag¬ 
er  role  speci¬ 
fications 

VER  SP 

3.2 

Analyze  the 
results  of  all 
verification  activ¬ 
ities. 

Filled-in  WEEK  forms  with 

Test  and  Quality  role  reports; 
SUMP/SUMQ  analyses;  PM 
results 

The  TSP+  provides  postmortem 
structure  for  analyzing  conduct 
and  results. 

SOFTWARE  ENGINEERING  INSTITUTE  |  51 


PSP/TSP 

CMMI 

CMMI  PA:  VER 

Direct  Artifact 

Guidance 

Reference 

Feature 

Verification 

Description 

VER  GG  2 

The  process  is 
institutionalized 
as  a  defined 
process. 

See  PIP 

ALL-1. 

VER  GP 

2.1 

Establish  and 
maintain  an 
organizational 
policy  for  plan¬ 
ning  and  per¬ 
forming  the 
verification 
process. 

Policy  is  not  addressed  in 

AIM. 

This  issue  to  be  addressed  by 
the  Implementation  Guide. 

Script  LAU3 

VER  GP 

2.2 

Establish  and 

maintain  the 
plan  for  perform¬ 
ing  the  verifica¬ 
tion  process. 

Scripts  TESTx,  REQ,  HLD, 

IMP,  IMP6,  form  SUMS,  form 
TASK 

Verification  activities  are  tasks 
in  the  individual  and  team 
plans. 

In  addition  to  role  plans,  the 
Quality  Manager,  Process 
Manager,  and  Support  Manag¬ 
er  may  have  verification-related 
activities. 

See  PIP 
ROLE-1. 

VER  GP 

2.3 

Provide  ade¬ 
quate  resources 
for  performing 
the  verification 
process,  devel¬ 
oping  the  work 
products,  and 
providing  the 
services  of  the 
verification 
process. 

Specific  tasks  in  individual 
and  consolidated  work  plans 
from  LAU3,  LAU4,  and 

LAU6,  recorded  in  TASK  and 
SCHEDULE 

The  TSP+  planning  process 
includes  verification  activities 
and  resources. 

See  PIP 
ROLE-1. 

VER  GP 

2.4 

Assign  respon¬ 
sibility  and  au¬ 
thority  for  per¬ 
forming  the 
process,  devel¬ 
oping  the  work 
products,  and 
providing  the 
services  of  the 
verification 
process. 

PREPL/PREPR,  LAU2  role 
assignments,  Team  Leader, 
and  Test  and  Quality  Man¬ 
ager  roles 

See  the  Quality  Manager  role, 
with  support  from  the  coach 
and  the  process  manager. 

VER  GP 

2.5 

Train  the  people 
performing  or 
supporting  the 
verification 
process  as 
needed. 

PSP  training  for  personal 
reviews  is  directly  applicable. 

PSP  training  provides  specific 
unit  test  instruction  and  individ¬ 
ual  and  peer  review.  However, 
further  aspects  of  testing  are 
not  addressed. 

There  is  no  guidance  or  refer¬ 
ence  on  specific  training  in 
integration,  system,  or  accep¬ 
tance  test  practices. 
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PSP/TSP 

Reference 


Guidance 


CMMI  CMMI  PA:  VER  Direct  Artifact 

Feature  Verification 

Description 


LOGCI  for  items  under  for¬ 
mal  configuration  manage¬ 
ment 

The  Support  Manager  role  is 
responsible  for  CM  for  the 
project.  The  work  products 
from  the  launch  will  be  CIs  in 
form  LOGCI  and  placed 
under  appropriate  control. 
Other  artifacts  will  be  placed 
under  informal  control. 

The  project  notebook 
Typically,  this  information 
would  appear  in  the  CM 
system  supported  by  the 
project  or  organization  (a 
protected  folder  on  a  drive, 
or  full  CM  with  CVS). 


Relevant  role 

managers 

(Design, 

Test,  Imple¬ 
mentation) 

See  PIP 

ALL-2 

VER  GP 

2.7 

Identify  and 
involve  the  rele¬ 
vant  stakehold¬ 
ers  of  the  verifi¬ 
cation  process 
as  planned. 

RSIM  (Relevant  Stakeholder 
Involvement  Matrix) 

Role  Assignment  Matrix 
ROLEMX 

Test  and 
Quality  Man¬ 
ager  role 
specifications 

VER  GP 

2.8 

Monitor  and 
control  the  veri¬ 
fication  process 
against  the  plan 
for  performing 
the  process  and 
take  appropriate 
corrective  ac¬ 
tion. 

Filled-in  WEEK  forms  show¬ 
ing  quality  manager  role 
reports,  replans,  plans  result¬ 
ing  from  relaunches 

VER  GP 

2.9 

Objectively  eva¬ 
luate  adherence 
of  the  verifica¬ 
tion  process 
against  its 
process  descrip¬ 
tion,  standards, 
and  procedures; 
address  non- 
compliance. 

Checkpoint  report  and  post¬ 
mortem  report 

The  Coach,  Team  Lead,  and 
Process  Manager  review 
Quality  Manager  reports  and 
verification  results. 

See  PIP  CM-  VER  GP  Place  designat- 

1 .  2.6  ed  work  prod¬ 

ucts  of  the  veri¬ 
fication  process 
under  appropri¬ 
ate  levels  of 
control. 


Quarterly 

VER  GP 

Review  the 

Weekly  and  management 

Review 

2.10 

activities,  status, 

status  reports 

Checklist  and 

and  results  of 

TASK  plans  that  show  the 

add  VER 

the  verification 

verification  activities  included 

focus 

process  with 

in  various  role  and  team 

higher  level 

member  activities.  These  can 

management ; 

be  reviewed  with  upper 

resolve  issues. 

management. 

Configuration  and  data  man¬ 
agement  are  planned  during 
launch  preparation.  CM 
processes  are  observed  and 
planning  CIs  are  entered  in 
form  LOGCI. 


See  the  Quality  manager  role 


See  the  Individual  weekly  sta¬ 
tus  review,  quality  manager  role 
report 


The  TSP  Coach  will  perform  a 
Checkpoint  to  evaluate  process 
and  work  products. 

During  the  launch,  the  Coach 
guides  process  fidelity,  includ¬ 
ing  VER.  As  the  project  ex¬ 
ecutes,  the  Team  Leader,  and 
Planning  and  Process  Manag¬ 
ers  objectively  evaluate.  The 
Coach  will  perform  a  formal 
objective  evaluation  in  the 
Checkpoint  and  the  PM. 

When  the  Process  Group  (PG) 
is  formed  the  Coaching  Man¬ 
ager  role  will  objectively  eva¬ 
luate  the  launch  process  and 
artifacts  for  each  launch. 

Verification  activities  are  critical 
to  quality  and  cost  of  quality. 
These  activities  and  results 
normally  are  of  particular  inter¬ 
est  to  management. 
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PSP/TSP 

CMMI 

CMWII  PA:  VER 

Direct  Artifact 

Guidance 

Reference 

Feature 

Verification 

Description 

VER  GP 

3.1 

Establish  and 
maintain  the 
description  of  a 
defined  verifica¬ 
tion  process. 

The  TSP+  role  of  Process 
Group  Support  Manager  is 
responsible  for  establishing 
and  maintaining  the  OSSP. 

The  OSSP  will  contain  the 
processes,  scripts,  and 
forms. 

The  Launch  Notebook 
(PREPL,  PREPR,  LAU1-9, 
WEEK) 

See  the  PG  Support  Manager 
and  PG  Process  Manager 
roles. 

VER  GP 

3.2 

Collect  work 
products,  meas¬ 
ures,  measure¬ 
ment  results, 
and  improve¬ 
ment  information 
derived  from 
planning  and 
performing  the 
verification 
process  to  sup¬ 
port  the  future 
use  and  im¬ 
provement  of 
the  organiza¬ 
tion’s  processes 
and  process 
assets. 

NOTEBOOK  regarding  veri¬ 
fication  activities 

The  Process  Asset  Library 
and  associated  collection 
mechanisms 

The  organizational  infrastruc¬ 
ture  (including  the  PAL  and 
the  measurement  repository) 
is  developed  by  the  Process 
Group;  see  OPF,  OPD. 

The  TSP+  has  been  expanded 
to  include  a  PG  Process  Asset 
and  Data  Repository  Manager. 
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3.2.6  Validation  (VAL) 


The  following  table  lists  the  elements  of  the  Validation  (VAL)  process  area  employed  in  the  AIM 
approach. 


TSP/PSP  CMMI  CMMI  PA:  VAL-Validation  Direct  Artifact  Guidance 

Reference  Feature  Description 


VAL  SG  1 


Preparation  for  validation 
is  conducted. 


Appropriate  development 
methodolog(ies)  will  need 
to  be  adopted  by  the 
organization.  These  me¬ 
thodologies  will  have 
their  own  artifacts  that 
will  need  to  be  substi¬ 
tuted  for  those  refe¬ 
renced  in  TSP+. 


Team 

VAL  SP 

Select  products  and  prod- 

Leader 

1.1 

uct  components  to  be 

and  Cus- 

validated  and  the  valida- 

tomer 

tion  methods  that  will  be 

Interface 
role  speci¬ 
fications; 
scripts 

REQ  and 
ANA 

used  for  each. 

Prototypes  to  resolve  impor¬ 
tant  specification  questions 


There  are  multiple  places 
throughout  the  TSP+  life 
cycle  where  validation 
selection  could  take 
place,  but  none  are  cur¬ 
rently  specified.  For  ex¬ 
ample,  in  REQ  or  ANA, 
the  SRS  could  record  the 
selection,  or  in  TEST3 
the  selection  could  be 
made  while  developing 
the  system  test  proce¬ 
dures  (probably  the  se¬ 
lection  is  made  de  facto 
here  in  the  absence  of 
any  other  choices).  A 
usability  test  is  an  exam¬ 
ple  of  a  validation  selec¬ 
tion,  which  can  occur 
early  during  prototype 
testing  or  late  during 
system  usability  tests. 
The  organization  should 
make  clear  how  prod¬ 
ucts/components  are 
selected  for  validation 
and  the  validation  me¬ 
thod  chosen. 


Script 
LAU3, 
Customer 
Interface 
and  Sup¬ 
port  Role 
Manager 
specifica¬ 
tions 


VAL  SP 
1.2 


Establish  and  maintain  the 
environment  needed  to 
support  validation. 


Filled-in  form  INV  as  called 
for  in  LAU3  steps  8  (devel¬ 
opment  tools  and  facilities); 
individuals’  TASK  plans  and 
LOGT  entries  related  to  this; 
test  plans  that  document  the 
validation  environment 


The  Customer  Interface 
and  Support  roles  have 
responsibility  for  specify¬ 
ing  and  building/obtaining 
the  validation  environ¬ 
ment  as  part  of  the  over¬ 
all  development  environ¬ 
ment  (which  is  explicitly 
called  out). 

There  is  no  explicit  direc¬ 
tion  for  establishing  the 
validation  environment. 
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TSP/PSP 

CMMI 

CMMI  PA:  VAL -Validation 

Direct  Artifact 

Guidance 

Reference 

Feature 

Description 

Scripts 

VAL  SP 

Establish  and  maintain 

System  Test  Plan  (called  for 

The  Customer  Interface 

DEV, 

1.3 

procedures  and  criteria  for 

in  TEST3)  including  usability 

Manager  clearly  has 

MAINT, 

validation. 

tests 

responsibility  for  advocat- 

REQ, 

ing  the  customer  point  of 

ANA, 

view,  while  the  Test 

TEST3 

Manager  has  responsi- 

Customer 

bility  for  developing  and 

Interface 

executing  these  tests 

Manager 

internally.  External  tests 

and  Test 

(e.g.,  on-site  customer 

Manager 

acceptance  tests)  proba- 

role  sped- 

bly  would  reside  with  the 

fications 

Customer  Interface  role, 
or  perhaps  the  Team 
Leader. 

There  is  no  standard 
template  or  criteria  for 
validation  test  proce¬ 
dures,  nor  is  there  specif¬ 
ic  guidance  for  the  Cus¬ 
tomer  Interface  and  Test 
Managers  to  develop 
such  procedures  and 
criteria. 

VAL  SG  2 

The  product  or  product 

Two  TSP  activities,  proto- 

components  are  validated 

typing  and  system  test- 

to  ensure  that  they  are 

ing,  seem  to  address  the 

suitable  for  use  in  their 

intent  of  validation.  Flow- 

intended  operating  envi- 

ever,  the  direction  in  the 

ronment. 

existing  TSP  process 
assets  is  sparse  and 
scattered. 

Scripts 

VAL  SP 

Perform  validation  on  the 

Prototypes  used  to  validate 

Direction  in  the  specified 

REQ, 

2.1 

selected  products  and 

important  specification  ques- 

scripts  is  extremely  high 

ANA, 

product  components. 

tions;  outputs  of  other  vali- 

level,  and  only  partially 

TEST3 

dation  activities  identified  by 

addresses  validation 

Forms 

the  Customer  Interface  role 

issues  in  the  form  of 

TESTLOG, 

usability  tests. 

LOGT, 

There  is  no  standard 

LOGD, 

template  or  criteria  for 

TASK 

recording  prototype  re- 

Customer 

suits  or  outcomes.  There 

Interface 

is  no  clear  delineation  in 

and  Test 

TESTLOG  between  vali- 

Manager 

dation  and  other  kinds  of 

role  speci¬ 
fications 

system  tests. 

Scripts 

VAL  SP 

Analyze  the  results  of  the 

PM  results 

The  weekly  team  meeting 

REQ, 

2.2 

validation  activities. 

WEEK  form  -  the  Customer 

and  postmortem  activi- 

ANA, 

Interface  Role  manager 

ties,  while  clearly  provid- 

TEST3, 

reports  on  the  status  of  re- 

ing  a  venue  for  such 

WEEK, 

quirements  development 

analyses,  provide  no 

PM 

specific  guidance  to  the 

Customer 

relevant  role  managers. 

Interface 

There  is  no  standard 

Manager 

template  or  criteria  for 

and  Test 
role  speci¬ 
fication. 

validation  data  analysis. 
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TSP/PSP 

CMMI 

CMMI  PA:  VAL -Validation  Direct  Artifact 

Guidance 

Reference 

Feature 

Description 

Script 

LAU3 


VAL  GG  3 

VALGP 

2.1 


VALGP 

2.2 


VALGP 

2.3 


VALGP 

2.4 


VALGP 

2.5 


VALGP 

2.6 


Relevant 
role  man¬ 
agers 
(Customer 
Interface) 
See  PIP 
ALL-2. 


VALGP 

2.7 


VALGP 

2.8 


The  process  is  institutiona¬ 
lized  as  a  defined  process. 

Establish  and  maintain  an 
organizational  policy  for 
planning  and  performing 
the  validation  process. 

Establish  and  maintain  the 
plan  for  performing  the 
validation  process. 


Provide  adequate  re¬ 
sources  for  performing  the 
validation  process,  devel¬ 
oping  the  work  products, 
and  providing  the  services 
of  the  process. 

Assign  responsibility  and 
authority  for  performing  the 
process,  developing  the 
work  products,  and  provid¬ 
ing  the  services  of  the 
validation  process. 

Train  the  people  perform¬ 
ing  or  supporting  the  vali¬ 
dation  process  as  needed. 


Place  designated  work 
products  of  the  validation 
process  under  appropriate 
levels  of  control. 


Identify  and  involve  the 
relevant  stakeholders  of 
the  validation  process  as 
planned. 


Monitor  and  control  the 
validation  process  against 
the  plan  for  performing  the 
process  and  take  appro¬ 
priate  corrective  action. 


No  policies  in  TSP+ 


Scripts  DEV,  MAINT,  REQ, 
ANA,  TEST3,  form  SUMS, 
form  TASK 


This  will  be  addressed  in 
the  AIM  implementation 
guide. 

The  validation  activities 
that  are  identified  during 
the  launch  have  an  es¬ 
tablished  and  maintained 
plan. 


Specific  tasks  in  individual 
and  consolidated  work  plans 
from  LAU3,  LAU4,  and 
LAU6,  recorded  in  forms 
INV,  TASK  &  SCHEDULE 

PREPL/PREPR,  LAU2  role 
assignments,  Team  Leader 
and  Customer  Interface 
Manager  role 


PSP  training,  as  well  as  on- 
the-job  training  provided  to 
role  managers  for  validation 
by  TSP  Coach  or  Team 
Leader  as  an  adjunct  to  the 
role  description 


LOGCI  for  items  under  for¬ 
mal  configuration  manage¬ 
ment 

The  Support  Manager  role  is 
responsible  for  CM  for  the 
project.  The  work  products 
from  the  launch  will  be  CIs  in 
form  LOGCI  and  placed 
under  appropriate  control. 
Other  artifacts  will  be  placed 
under  informal  control. 

The  project  notebook 
Typically,  this  information 
would  appear  in  the  CM 
system  supported  by  the 
project  or  organization  (a 
protected  folder  on  a  drive, 
or  full  CM  with  CVS). 


Validation  activities  will 
be  in  the  individual  task 
plans,  including  the  role 
plan. 


There  is  no  guidance  or 
reference  on  specific 
training  in  validation  prac¬ 
tices  in  the  TSP+. 


Configuration  and  data 
management  are  planned 
during  launch  prepara¬ 
tion.  CM  processes  are 
observed  and  planning 
CIs  are  entered  in  form 
LOGCI. 


RSIM  (Relevant  Stakeholder 
Involvement  Matrix) 

Role  Assignment  Matrix 
ROLEMX 


See  the  Quality  Manager 
role. 


Filled-in  WEEK  forms  show¬ 
ing  Quality  Manager  role 
reports,  replans,  plans  re¬ 
sulting  from  relaunches 


See  individual  weekly 
status  review,  quality 
manager  role  report. 
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TSP/PSP 

CMMI 

CMMI  PA:  VAL -Validation  Direct  Artifact 

Guidance 

Reference 

Feature 

Description 

VAL  GP 

2.9 

Objectively  evaluate  adhe¬ 
rence  of  the  validation 
process  against  its  process 
description,  standards,  and 
procedures;  address  non- 
compliance. 

Checkpoint  report  and 
postmortem  report 

The  Coach,  Team  Lead,  and 
Process  Manager  review 
Customer  Interface  and 

Cuality  Manager  reports  and 
validation  results 

The  TSP  Coach  will  per¬ 
form  a  Checkpoint  to 
evaluate  process  and 
work  products. 

During  the  launch,  the 
coach  guides  process 
fidelity,  including  VAL.  As 
the  project  executes,  the 
Team  Leader,  and  Plan¬ 
ning  and  Process  Man¬ 
agers  objectively  eva¬ 
luate.  The  Coach  will 
perform  a  formal  objec¬ 
tive  evaluation  in  the 
checkpoint  and  the  PM. 
When  the  Process  Group 
(PG)  is  formed,  the 
Coaching  Manager  role 
will  objectively  evaluate 
the  launch  process  and 
artifacts  for  each  launch. 

VAL  GP 
2.10 

Review  the  activities,  sta¬ 
tus,  and  results  of  the 
validation  process  with 
higher  level  management ; 
resolve  issues. 

TASK  plans  that  show  the 

VAL  activities  included  in 
various  role  and  team  mem¬ 
ber  activities.  These  can  be 
reviewed  with  upper  man¬ 
agement. 

VAL  activities  are  typical¬ 
ly  included  in  TASK  plans 
that  are  regularly  re¬ 
viewed. 

VAL  GP 

3.1 

Establish  and  maintain  the 
description  of  a  defined 
validation  process. 

The  TSP+  role  of  Process 
Group  Support  Manager  is 
responsible  for  establishing 
and  maintaining  the  OSSP. 
The  OSSP  will  contain  the 
processes,  scripts,  and 
forms. 

The  Launch  Notebook 
(PREPL,  PREPR,  LAU1-9, 
WEEK) 

See  the  PG  Support 
Manager  and  PG  process 
manager  roles. 

VAL  GP 

3.2 

Collect  work  products, 
measures,  measurement 
results,  and  improvement 
information  derived  from 
planning  and  performing 
the  validation  process  to 
support  the  future  use  and 
improvement  of  the  organ¬ 
ization’s  processes  and 
process  assets. 

NOTEBOOK  regarding  veri¬ 
fication  activities. 

The  Process  Asset  Library 
and  associated  collection 
mechanisms 

The  organizational  infra¬ 
structure  (including  the  PAL 
and  the  measurement  repo¬ 
sitory)  is  developed  by  the 
Process  Group;  see  OPF, 
OPD. 

The  TSP+  has  been 
expanded  to  include  a 

PG  Process  Asset  and 

Data  Repository  Manag¬ 
er. 

SOFTWARE  ENGINEERING  INSTITUTE  |  58 


3.3  Process  Management  Processes 
3.3.1  Organizational  Process  Focus  (OPF) 

The  following  table  lists  the  elements  of  the  Organizational  Process  Focus  (OPF)  process  area 
employed  in  the  AIM  approach. 


TSP 

Reference 

CMMI 

Feature 

CMMI  PA: 
Organizational 
Process  Focus 
Description 

OPF SG  1 

Strengths,  weak¬ 
nesses,  and  im¬ 
provement  oppor¬ 
tunities  for  the 
organization’s 
processes  are 
identified  periodi¬ 
cally  and  as 
needed. 

POPS, 

OPF  SP  1.1 

Establish  and 

POPS7, 

maintain  the  de- 

Process 

scription  of  the 

Group  Roles 

process  needs 

and  Re- 

and  objectives  for 

sponsibili- 
ties,  LAU1 

the  organization. 

Process 

OPF  SP  1.2 

Appraise  the  or- 

Group  Roles 

ganization’s 

and  Re- 

processes  periodi- 

sponsibilities 

cally  and  as 
needed  to  main¬ 
tain  an  under¬ 
standing  of  its 
strengths  and 
weaknesses. 

Direct  Artifact 


It  is  management’s  re¬ 
sponsibility  to  determine 
the  needs  and  objectives 
of  all  TSP  teams,  including 
the  PG.  Management 
presents  needs  and  objec¬ 
tives  to  the  team  during 
meeting  1,  thus  the  organ¬ 
ization’s  process  needs 
and  objectives  should  be 
documented  in  manage¬ 
ment’s  meeting  1  presen¬ 
tation  to  the  PG,  as  it  is 
the  PG’s  responsibility  to 
change,  establish,  main¬ 
tain,  and  improve  the  or¬ 
ganization’s  stated  needs 
and  objectives. 


Appraisal  results 
Checkpoint,  postmortems 
The  PG  Team  is  responsi¬ 
ble  for  periodically  apprais¬ 
ing  the  organizations 
processes. 


Guidance 


TSP+  now  includes  provisions 
for  the  formation  and  manage¬ 
ment  of  the  Process  Group 
(PG). 


In  some  cases  the  PG  Team 
Lead  may  help  management  in 
the  development  and  articula¬ 
tion  of  the  organization's 
process  needs  and  objectives 
for  the  organization. 


Appropriate  classes  of  SCAM- 
PIs  should  be  a  feature  of  the 
AIM  strategy,  necessarily  cul¬ 
minating  in  a  SCAMPI  A  if  a 
level  rating  is  desired. 
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TSP 

Reference 


PIP, 

LOGPIP, 
LOGSPDR, 
SPDE,  PM 


POPS, 

POPS7 


PSP  and 
TSP  training 
records; 

TSP  launch 
preparation 
artifacts 
(e.g.,  meet¬ 
ing  minutes, 
team  as¬ 
signment 
memos) 

See  PIP 
OPF-2. 


CMMI 

Feature 


OPFSP  1.3 


OPF SG  3 


CMWII  PA: 
Organizational 
Process  Focus 
Description 

Identify  improve¬ 
ments  to  the  or¬ 
ganization’s 
processes  and 
process  assets. 


Direct  Artifact 


Filled-in  PIPs  (Process 
Improvement  Proposals) 
Completed  Process  Devia¬ 
tion  Evaluations  (SPDE) 
The  PG  Team  Lead  has 
the  responsibility  to  Identi¬ 
fy  priority  areas  for  im¬ 
provement. 


Guidance 


The  TSP  emphasizes  this  from 
a  personal  and  project  perspec¬ 
tive.  The  Process  Manager  is 
responsible  at  the  team  level  for 
processing  PIPs  (Process  Im¬ 
provement  Proposals)  and  oth¬ 
erwise  focusing  on  team 
process  improvements. 

The  PG  Team  Lead  and  the  PG 
Process  Manager  extends  this 
imperative  to  the  organization 
level. 

As  part  of  the  team  postmortem 
(PM)  process  the  team  is  re¬ 
sponsible  for  evaluating  all 
approved  Standard  Process 
Deviation  Request  against  the 
OSSP  and  providing  this  evalu¬ 
ation  (SPDE)  to  the  process 
group. 


OPF SG  2 

Process  actions 

that  address  im¬ 
provements  to  the 
organization’s 
processes  and 
process  assets 
are  planned  and 
implemented. 

OPFSP  2.1 

Establish  and 
maintain  process 
action  plans  to 
address  improve¬ 
ments  to  the  or¬ 
ganization’s 
processes  and 
process  assets. 

The  PG  TSP  plan  will 
include  actions  to  address 
improvements  to  the  or¬ 
ganizations  process  as¬ 
sets. 

See  POPS  7  for  establish¬ 
ing  the  PG. 

The  PG  will  have  a  TSP  plan 
that  will  include  the  action  plans 
for  improving  the  organization’s 
processes  and  process  assets. 

OPFSP  2.2 

Implement 
process  action 
plans. 

The  PG  TSP  plan  and  tool 
will  show  the  implementa¬ 
tion  of  the  action  plan. 

The  PIP  evaluations 

Typically  there  are  many  arti¬ 
facts  resulting  from  a  particular 
TSP  implementation. 

PIP  evaluation  and  implementa- 

The  organizational 
process  assets 
are  deployed 
across  the  organi¬ 
zation  and 
process-related 
experiences  are 
incorporated  into 
the  organizational 
process  assets. 


tion  (e.g.,  changing  process 
elements  via  the  ODP  process) 
should  be  part  of  the  PG  team 
and  handled  as  a  TSP  project. 
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TSP 

Reference 


PREPT, 
LAU3, 
Process 
Manager 
Roles  and 
Responsi¬ 
bilities 


PREPT, 

LAU3, 

CYCLE 


Checkpoint 


CMMI  CM  Ml  PA:  Direct  Artifact  Guidance 

Feature  Organizational 


Process  Focus 
Description 


OPFSP3.1 

Deploy  organiza¬ 
tional  process 
assets  across  the 
organization. 

Checkpoint  for  each 
project  will  evaluate  the 
process  and  assets  used 
for  the  project. 

Each  project  will  tailor  the 
OSSP,  creating  the  PSSP 
(Project  Specific  Software 
Process).  The  PSSP  will 
be  in  the  project  notebook. 
(CMMI  calls  this  the  PDP 
projects  defined  process.) 
Deviations  request  and 
approved  waivers  will  be 
recorded  in  form  SPDR. 

The  Team  TSP  plan  will 
reflect  the  tasks  and  work 
products  consistent  with 
the  PSSP. 

During  team  preparations 
for  a  launch  or  relaunch 
the  team  will  either  estab¬ 
lish  the  project's  set  of 
standard  processes  from 
the  current  OSSP,  or  if  a 
PSSP  already  exists,  re¬ 
view  any  changes  or  up¬ 
dates  to  the  OSSP  since 
the  last  launch  or  relaunch 
for  incorporation  into  the 
existing  PSSP. 

The  innovations  are  deployed 
across  the  organization  project 
by  project  in  the  launch  and 
relaunch  process. 

The  process  manager  role  for 
each  project  is  responsible  for 
ensuring  that  the  project  uses 
the  appropriate  process  and 
process  assets.  LAU3  steps  6 
and  7. 

OPFSP3.2 

Deploy  the  organi¬ 
zation’s  set  of 
standard 
processes  to 
projects  at  their 
startup  and  deploy 
changes  to  them 
as  appropriate 
throughout  the  life 
of  each  project. 

During  each  launch  (or  re¬ 
launch)  in  LAU3  steps  6 
and  7,  the  process  man¬ 
ager  leads  the  team  in 
creating  the  development 
process  (PSSP).  The 
Process  Manager  will  also 
update  the  processes  if 
changes  must  be  made 
between  launches. 

In  general,  changes  to  the 

PSSP  will  only  occur  at  the 
beginning  of  each  TSP  cycle. 

They  may  change  within  a 
cycle,  but  this  usually  only  oc¬ 
curs  if  the  current  process  is 
determined  to  be  unusable. 

OPF  SP  3.3 

Monitor  the  im¬ 
plementation  of 
the  organization’s 
set  of  standard 
processes  and 
use  of  process 
assets  on  all 
projects. 

TSP  Checkpoint  results 

The  role  of  the  PG  Coach¬ 
ing  Manager  is  responsible 
for  reviewing  Checkpoint 
results  from  all  the  coach¬ 
es  and  reviewing  launch 
artifacts.  The  PG  coach 
will  report  results. 

The  PG  Team  Lead  re¬ 
views  the  Process  Manag¬ 
er  reports  from  WEEK 
minutes. 

PM  results  for  each  project 
for  proper  implementation 
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TSP 

Reference 

CMMI 

Feature 

CMWII  PA: 
Organizational 
Process  Focus 
Description 

Direct  Artifact 

Guidance 

OPFSP3.4 

Incorporate 
process-related 
work  products, 
measures,  and 
improvement  in¬ 
formation  derived 
from  planning  and 
performing  the 
process  into  the 
organizational 
process  assets. 

The  PAL  (Process  Asset 
Library) 

The  PG  role  of  Process  Asset 
and  Data  Repository  Manager 
is  responsible  for  establishing 
and  maintaining  the  PAL. 

OPF GG  2 

The  process  is 
institutionalized  as 
a  managed 
process. 

OPF  GP  2.1 

Establish  and 
maintain  an  orga¬ 
nizational  policy 
for  planning  and 
performing  the 
organizational 
process  focus 
process. 

Policy  will  be  specific  to 
each  organization. 

This  issue  to  be  addressed  by 
the  Implementation  Guide 

POPS, 

Process 

Group  Roles 
and  Re¬ 
sponsibilities 
Process 
Manager 
Roles  and 
Responsi¬ 
bilities 

OPF  GP  2.2 

Establish  and 
maintain  the  plan 
for  performing  the 
organizational 
process  focus 
process. 

The  PG  TSP  will  include 
OPF  activities,  the  Process 
Manager  role,  the  Support 
Manager  role,  the  Coach 
role,  the  Team  Lead  role, 
and  the  Process  Asset  and 
Data  Repository  Manager 
role. 

In  addition  to  the  PG  the 
Process  Managers  for 
each  team  will  ensure  that 
the  appropriate  process 
and  process  assets  are 
employed  for  the  project. 

The  major  responsibility  for 

OPF  resides  with  the  PG  and 
the  specialized  roles.  The  PG 
plan  will  be  monitored  and  con¬ 
trolled  using  the  PMC  process. 

LAU 

OPF  GP  2.3 

Provide  adequate 
resources  for  per¬ 
forming  the  orga¬ 
nizational  process 
focus,  developing 
the  work  products, 
and  providing  the 
services  of  the 
process. 

The  PG  TSP  Plan 

The  TSP  launch  and  plan  for 
the  PG  provides  for  adequate 
resources  for  the  OPF  activities. 

RSIM, 

SRAM 

OPF  GP  2.4 

Assign  responsi¬ 
bility  and  authority 
for  performing  the 
process,  develop¬ 
ing  the  work  prod¬ 
ucts,  and  provid¬ 
ing  the  services  of 
the  organizational 
process  focus. 

The  roles  in  the  PG  plan 
and  the  SRAM  (Stake¬ 
holder  Role  Assignment 
Matrix) 

The  PG  role  specifications  and 
the  SFtAM  for  the  PG  will  identi¬ 
fy  OPF  responsibility. 
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TSP 

Reference 

CMMI 

Feature 

CMMI  PA: 
Organizational 
Process  Focus 
Description 

Direct  Artifact 

Guidance 

POPS, 

TRNM, 

LOGTRNM 

OPFGP2.5 

Train  the  people 
performing  or 
supporting  the 
organizational 
process  focus  as 
needed. 

TRNM  (Training  Matrix) 
and  LOGTRNM  (Team 
Member  Training  Log)  and 
SRAM 

LOGCI 

OPFGP2.6 

Place  designated 
work  products  of 
the  organizational 
process  focus 
under  appropriate 
levels  of  control. 

LOGCI  (Configuration  Item 
Log)  will  contain  the  OPF 
work  products  and  appro¬ 
priate  levels  of  control;  see 
CM  PA. 

SRAM, 

RSIM,  LAU 

OPFGP2.7 

Identify  and  in¬ 
volve  the  relevant 
stakeholders  of 
the  organizational 
process  focus  as 
planned. 

PG  project  notebook 

PG  TSP  Plan 

RSIM  (Relevant  Stake¬ 
holder  Involvement  Matrix) 

STATUS, 

WEEK 

OPFGP2.8 

Monitor  and  con¬ 
trol  the  organiza¬ 
tional  process 
focus  against  the 
plan  for  perform¬ 
ing  the  process 
and  take  appropri¬ 
ate  corrective 
action. 

Filled-in  WEEK  form  and 
weekly  meeting  minutes 
from  the  PG  team  plan 
Minutes  from  PG  man¬ 
agement  reviews 

CHECKPOI 
NT,  CYCLE 

OPFGP2.9 

Objectively  eva¬ 
luate  adherence  of 
the  organizational 
process  focus 
against  its  process 
description,  stan¬ 
dards,  and  proce¬ 
dures,  and  ad¬ 
dress 

noncompliance. 

Checkpoint  for  the  PG 
team 

The  PG  functions  as  a  TSP 
team  so  there  will  be  a  launch 
and  a  TSP  plan.  In  addition 
there  will  be  a  coach,  Check¬ 
point  review,  and  postmortem 
review. 

It  is  assumed  that  the  PG  coach 
will  have  a  direct  line  to  man¬ 
agement  in  order  to  help  main¬ 
tain  objectivity. 

STATUS 

OPF  GP 

2.10 

Review  the  activi¬ 
ties,  status,  and 
results  of  the  or¬ 
ganizational 
process  focus  with 
higher  level  man¬ 
agement  ;  resolve 
issues. 

PG  Management  meeting 
minutes 

The  PG  will  conduct  status 
reviews,  just  like  any  other  TSP 
project. 

Process 

Group  roles 
and  respon¬ 
sibilities 

OPF  GP  3.1 

Establish  and 
maintain  the  de¬ 
scription  of  a  de¬ 
fined  organiza¬ 
tional  process 
focus. 

Individual  and  team  plans 
include  tasks  for  peer 
reviews 

The  PG  Process  Manager 
working  with  the  PG  Support 
Manager,  and  PG  Process 

Asset  and  Data  Repository 
Manager  will  establish  and 
maintain  the  description  of  the 
organizational  process  focus. 
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Direct  Artifact 


Guidance 


TSP 

Reference 


Process 
Group  roles 
and  respon¬ 
sibilities 


CMMI 

Feature 


CMMI  PA: 
Organizational 
Process  Focus 
Description 


OPFGP3.2 

Collect  work  prod- 

The  Process  Asset  Library 

The  TSP+  has  been  expanded 

ucts,  measures, 

and  associated  collection 

to  include  a  PG  Process  Asset 

measurement 

mechanisms 

and  Data  Repository  Manager 

results,  and  im- 

The  organizational  infra- 

who  will  be  responsible  for  the 

provement  infor- 

structure  (including  the 

design  and  development  of  the 

mation  derived 
from  planning  and 
performing  the 
organizational 
process  focus  to 
support  the  future 
use  and  improve¬ 
ment  of  the  organ¬ 
ization’s 
processes  and 
process  assets. 

PAL  and  the  measurement 
repository)  is  developed  by 
the  Process  Group.  This 
includes  appropriate  work 
products  and  measure¬ 
ment  results  and  im¬ 
provement  information  for 
the  OPF  process. 

PAL 
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3.3.2  Organizational  Process  Definition  +  IPPD  (OPD) 

The  following  table  lists  the  elements  of  the  Organizational  Process  Definition  +  IPPD  (OPD) 
process  area  employed  in  the  AIM  approach. 


TSP 

CMMI 

CMMI  PA:  Organizational 

Direct  Artifact 

Guidance 

Reference 

Feature 

Process  Definition  +  IPPD 

POPS, 
Process 
Group  roles 
and  respon¬ 
sibilities 


CYCLD, 
DEV,  MAINT 


PSSPE 


Process 
Group  roles 
and  respon¬ 
sibilities 


Process 
Group  roles 
and  respon¬ 
sibilities 


OPD  SG  1 

A  set  of  organizational  process 
assets  is  established  and 
maintained. 

OPD  SP 

Establish  and  maintain  the 

The  OSSP  (Organiza- 

1.1 

organization’s  standard 

tion  Set  of  Standard 

processes. 

Processes) 

The  PG  Process 
manager  and  the  PG 
Support  Manager  are 
responsible  for  estab¬ 
lishing  and  maintain¬ 
ing  the  OSSP. 

TSP  Process  Note¬ 
book 

TSP  Launch  Prepara¬ 
tion  Package 

OPD  SP 

Establish  and  maintain  de- 

The  OSSP 

1.2 

scriptions  of  the  life-cycle 

Script  CYCLE,  DEV, 

models  approved  for  use  in  the 

and  MAINT  in  the 

organization. 

Organizational 

Process  Notebook(s) 

OPD  SP 

Establish  and  maintain  the 

The  PG  Process 

1.3 

tailoring  criteria  and  guidelines 

Manager  is  responsi- 

for  the  organization’s  set  of 

ble  for  the  OSSP, 

standard  processes. 

including  Tailoring 
Guidelines. 

A  minimum  set  of 
tailoring  criteria  is 
included  as  part  of 
script  PSSPE 
(Projects  Set  of  Stan¬ 
dard  Processes  Es¬ 
tablishment).  The  PG 
may  determine  that 
additional  criteria  are 
needed  in  order  to 
meet  the  organiza¬ 
tional  process  needs 
and  objectives. 

OPD  SP 

Establish  and  maintain  the 

The  organization’s 

1.4 

organization’s  measurement 

Measurement  Reposi- 

repository. 

tory 

TSP  workbooks 
(filled-in) 

PM  results,  Check¬ 
points 

OPD  SP 

Establish  and  maintain  the 

The  Organizations 

1.5 

organization’s  process  asset 
library. 

PAL 

The  direct  artifact  should  be 
some  form  of  the  organization’s 
TSP  Process  notebooks.  This 
forms  the  organization’s  OSP. 
Projects  are  tailored  from  this 
notebook. 

CMMI  appraisers  should  review 
the  TSP  process  notebooks  to 
include  scripts,  forms,  tem¬ 
plates,  checklists,  and  specifi¬ 
cations. 


For  standard  TSP  these  are 
described  in  scripts  CYCLE, 
DEV,  and  MAINT.  Organiza¬ 
tions  may  have  more  life  cycles 
(e.g.,  Agile,  RUP)  reflected  in 
the  OSSP  or  the  project  note¬ 
books).  A  CMMI  start-up  pack¬ 
age  should  include  documenta¬ 
tion  of  the  existing  life  cycle(s). 


The  PG  role  of  Process  Asset 
and  Repository  Manager  is 
responsible  for  setting  up  the 
Measurement  repository. 


The  PG  role  of  Process  Asset 
and  Data  Repository  Manager 
is  responsible  for  the  PAL. 
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Reference  Feature  Process  Definition  +  IPPD 

Process 

Group  roles 
and  respon¬ 
sibilities, 
Support 
Manager 
roles  and 
responsibili¬ 
ties,  LAU3, 
PREPL, 
PREPR 

OPD  SP 

1.6 

Establish  and  maintain  work 
environment  standards. 

The  PG  Support 
Manager  role  estab¬ 
lishes  and  maintains 
the  organizational 
work  environment 
standards. 

LAU3  step  8  reviews 
the  work  environment 
and  lists  needed 
items.  The  Support 
Manager  role  is  re¬ 
sponsible  for  main¬ 
taining  a  productive 
work  environment 
including  environment 
standards 

PREPL/PREPR  call 
out  work  environment 
requirements  (facili¬ 
ties  and  tools)  for  the 
launch. 

OPD  SG  2 

Organizational  rules  and 
guidelines,  which  govern  the 
operation  of  integrated  teams, 
are  provided. 

See  TSPm  (TSP  mul¬ 
ti-team)  material  for 
IPPD. 

OPD  SP 

2.1 

Establish  and  maintain  empo¬ 
werment  mechanisms  to  ena¬ 
ble  timely  decision  making. 

See  TSPm  material 
for  IPPD. 

OPD  SP 

2.2 

Establish  and  maintain  organi¬ 
zational  rules  and  guidelines 
for  structuring  and  forming 
integrated  teams. 

See  TSPm  material 
for  IPPD. 

OPD  SP 

2.3 

Establish  and  maintain  organi¬ 
zational  guidelines  to  help 
team  members  balance  their 
team  and  home  organization 
responsibilities. 

See  TSPm  material 
for  IPPD. 

OPD  GG  2 

The  process  is  institutionalized 
as  a  managed  process. 

OPD  GP 

2.1 

Establish  and  maintain  an 
organizational  policy  for  plan¬ 
ning  and  performing  the  orga¬ 
nizational  process  definition 
process. 

Policy  will  be  specific 
to  each  organization. 

This  issue  to  be  addressed  by 
the  Implementation  guide. 

LAU 

OPD  GP 

2.2 

Establish  and  maintain  the 
plan  for  performing  the  organi¬ 
zational  process  definition 
process. 

The  PG’s  Process 
Group)  TSP  Plan  will 
include  the  plans  for 
the  PG  Process  Man¬ 
ager,  PG  Support 
Manager,  and  the  PG 
Process  Asset  and 

Data  repository  Man¬ 
ager. 

LAU 

OPD  GP 

2.3 

Provide  adequate  resources 
for  performing  the  organiza¬ 
tional  process  definition 
process,  developing  the  work 
products,  and  providing  the 
services  of  the  process. 

The  PG  plan,  see 
above,  and  the  PG 
Support  Managers 

INV  and  support  plan 
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RSIM, 

SRAM, 

ROLE 

OPD  GP 

2.4 

Assign  responsibility  and  au¬ 
thority  for  performing  the 
process,  developing  the  work 
products,  and  providing  the 
services  of  the  organizational 
process  definition  process. 

The  PG  TSP  plan  will 
have  the  role  assign¬ 
ment  also  in  form 

ROLE  and  SRAM. 

TRNM, 

LOGTRNM 

OPD  GP 

2.5 

Train  the  people  performing  or 
supporting  the  organizational 
process  definition  process  as 
needed. 

TRNM  (Training  Ma¬ 
trix)  and  LOGTRNM 
PSP  and  TSP  training 
records  for  both  full- 
and  part-time  PG 
members 

LOGCI, 

NOTEBOOK 

OPD  GP 

2.6 

Place  designated  work  prod¬ 
ucts  of  the  organizational 
process  definition  process 
under  appropriate  levels  of 
control. 

OSSP,  PAL,  Mea¬ 
surement  and  other 
OPD  work  products 
will  be  configuration 
items  in  the  CM  sys¬ 
tem. 

Form  LOGCI. 

As  with  any  other  TSP 
team,  the  informally 
controlled  items  will 
reside  in  the  project 
notebook. 

The  OPD  work  products  OSSP, 
PAL,  and  Measurement  Reposi¬ 
tory  will  all  be  CIs  in  the  CM 
system  and  placed  under  ap¬ 
propriate  levels  of  control. 

RSIM, 

RSAM 

OPD  GP 

2.7 

Identify  and  involve  the  rele¬ 
vant  stakeholders  of  the  orga¬ 
nizational  process  definition  as 
planned. 

RSIM 

PG  TSP  Plan 

WEEK,  PM 

OPD  GP 

2.8 

Monitor  and  control  the  orga¬ 
nizational  process  definition 
process  against  the  plan  for 
performing  the  process  and 
take  appropriate  corrective 
action. 

PG  TSP  Plan  moni¬ 
tored  using  PMC 
Filled-in  WEEK  form 
and  weekly  meeting 
minutes  from  the  PG 

team 

The  main  mechanism  for  moni¬ 
toring  and  controlling  is  the 

PMC  of  TSP  plans. 

See  the  management  meetings 
and  presentations.  In  some 
ways  Checkpoint  and  PM  also. 

CHECKPOI 

NT 

OPD  GP 

2.9 

Objectively  evaluate  adhe¬ 
rence  of  the  organizational 
process  definition  process 
against  its  process  description, 
standards,  and  procedures; 
address  noncompliance. 

PG  Checkpoint 

The  main  mechanism  for  objec¬ 
tive  evaluation  is  the  Check¬ 
point. 

STATUS 

OPD  GP 

2.10 

Review  the  activities,  status, 
and  results  of  the  organiza¬ 
tional  process  definition 
process  with  higher  level  man¬ 
agement  ;  resolve  issues. 

PG  management 
reviews 

CIBPS 

OPD  GP 

3.1 

Establish  and  maintain  the 
description  of  a  defined  orga¬ 
nizational  process  definition 
process. 

The  OSSP  will  include 
the  organizational 
process  definition 
process.  The  OSSP 
will  be  defined  using 
the  CIBPS  (Configura¬ 
tion  Item  Baseline, 

Plan,  and  Status)  form 
and  maintained  using 
the  CM  process. 

The  PG  Process  Manager 
working  with  the  PG  Support 
Manager,  and  PG  Process 

Asset  and  Data  Repository 
Manager  will  establish  and 
maintain  the  description  of  the 
organization’s  process  definition 
process  using  the  established 

CM  process. 
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TSP 

Reference 

CMMI 

Feature 

CMMI  PA:  Organizational 
Process  Definition  +  IPPD 

Direct  Artifact 

Guidance 

Process 

Group  roles 
and  respon¬ 
sibilities 

OPD  GP 

3.2 

Collect  work  products,  meas¬ 
ures,  measurement  results, 
and  improvement  information 
derived  from  planning  and 
performing  the  OPD  process 
to  support  the  future  use  and 
improvement  of  the  organiza¬ 
tion’s  processes  and  process 
assets. 

The  Process  Asset 
Library  and  asso¬ 
ciated  collection  me¬ 
chanisms 

The  organizational 
infrastructure  (includ¬ 
ing  the  PAL  and  the 
measurement  reposi¬ 
tory)  is  developed  by 
the  Process  Group. 

The  TSP+  has  been  expanded 
to  include  a  PG  Process  Asset 
and  Data  Repository  Manager 
who  will  be  responsible  for  the 
design  and  development  of  the 
PAL. 
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3.3.3  Organizational  Training  (OT) 


The  following  table  lists  the  elements  of  the  Organizational  Training  (OT)  process  area  employed 
in  the  AIM  approach. 


TSP/PSP 

CMMI 

CMMI  PA:  Organiza- 

Direct  Artifact 

Guidance 

Reference 

Feature 

tional  Training 
Description 

OT  SGI 

A  training  capability, 

which  supports  the  or¬ 
ganization’s  management 
and  technical  roles,  is 
established  and  main¬ 
tained. 


Specification 

TRN 

Process  Group 
roles  and  re¬ 
sponsibilities, 
TRNM 


OTSP1.1  Establish  and  maintain 
the  strategic  training 
needs  of  the  organiza¬ 
tion. 


The  Process  Group 
role  of  Training  Man¬ 
ager  is  responsible  for 
defining  the  training 
needs  of  the  organi¬ 
zation. 


See  Process  Group  Roles- 
Training  Manager. 


INV, 

PREPT, 

TRNR, 

TRNM, 

LAU3 


The  Training  Matrix 
(TRNM)  is  used  to 
capture  the  imme¬ 
diate  needs  of  the 
organization’s 
projects  and  the  long¬ 
term  business  objec¬ 
tives  of  the  organiza¬ 
tion. 


OT  SP  1.2  Determine  which  training 
needs  are  the  responsi¬ 
bilities  of  the  organization 
and  which  will  be  left  to 
the  individual  project  or 
support  group. 


The  Support  Manager 
role  for  the  project  will 
develop  the  project’s 
training  needs  and 
record  those  on  form 
INV. 

Form  TRNM  (Training 
Matrix)  lists  the  train¬ 
ing  required  for  the 
primary  roles  with  the 
project  and  organiza¬ 
tion. 

Form  TRNR  (Training 
Request)  is  used  to 
document  who  is 
responsible  for  fund¬ 
ing  the  training  for  the 
given  need. 


During  launch  preparations 
(PREPT)  the  Team  Leader 
will  meet  with  the  Training 
Manager  to  ensure  that  all 
training  requirements  have 
been  met  and  obtain  a  list  of 
all  outstanding  training  re¬ 
quirements  and  a  schedule 
for  all  mandatory  training  so 
that  the  team  can  account 
for  training  requirements  in 
its  project  plan. 

See  LAU3  steps  7  and  8  for 
Process  and  Support  Man¬ 
ager,  respectfully,  eliciting 
and  recording  project  train¬ 
ing  needs. 

Training  responsibility  is 
determined  during  the  train¬ 
ing  request  and  approval 
process. 


Process  Group  OTSP1.3  Establish  and  maintain  The  Process  Group’s 
roles  and  re-  an  organizational  training  Training  Manager  is 

sponsibilities  tactical  plan.  responsible  for  devel¬ 

oping  the  organiza¬ 
tional  training  tactical 
plan. 


See  the  PG  Training  Man¬ 
ager  role. 

This  is  the  responsibility  of 
the  Training  Manager. 


SOFTWARE  ENGINEERING  INSTITUTE  |  69 


TSP/PSP 

CMMI 

CMMI  PA:  Organiza¬ 

Direct  Artifact 

Guidance 

Reference 

Feature 

tional  Training 

Description 

POPS7,  TOPS, 

PREPL 

Process  Group 
roles  and  re¬ 
sponsibilities, 

TRN 

OT  SP  1.4 

Establish  and  maintain  a 
training  capability  to  ad¬ 
dress  organizational 
training  needs. 

The  PG  training  man¬ 
ager  will  develop  the 
training  capability 
based  on  the  TRNR 
(Training  Requests), 
and  standard  training 
in  the  TRNM  (Training 
Matrix)  and  TRNOJT 
(On-the-Job  Training). 
The  TSP  Introduction 
Strategy  addresses 
the  capability  for  PSP 
and  TSP,  and  those 
training  records  are 
available. 

The  PG  Training  Manager 
addresses  the  broader  on¬ 
going  training  capability 
needs  of  the  organization. 

The  PSP/TSP  training  ca¬ 
pability  is  covered  in  the 

TSP  Introduction  Strategy 
as  part  of  “building  internal 
capability”  for  supporting 

PSP  developers  on  TSP 
teams. 

OT  SG2 

Training  necessary  for 
individuals  to  perform 
their  roles  effectively  is 
provided. 

TRNSI, 

TRNSUR, 

SUMTRNS, 

TRNR, 

OT  SP  2.1 

Deliver  the  training  fol¬ 
lowing  the  organizational 
training  tactical  plan. 

TRNSI  (Training  Sign 
In),  TRNSUR  (Train¬ 
ing  Survey  Form), 
TRNR  (Training  Re¬ 
quests)  and 

SUMTRNS  (Training 
Summary  Survey) 

The  PG  Training  Manager  is 
responsible  for  establishing 
the  training  needs,  the  train¬ 
ing  plan  and  delivery,  docu¬ 
mentation,  and  evaluation  of 
training. 

LOGTRN, 

LOGTRNM, 

TRNSI, 

TRNSUR, 

TRNOJT, 

LOGTRN 

OT  SP  2.2 

Establish  and  maintain 
records  of  the  organiza¬ 
tional  training. 

Forms:  LOGTRNM 
(Team  Member  Train¬ 
ing  Log),  TRNSI 
(Training  Sign  In), 
Tactical  Training 

Plan,  TRNSUR 
(Training  Survey), 
TRNOJT  (On-the-Job 
Training),  LOGTRN 
(Training  Request 

Log) 

Course  rosters  and 
evaluations  for  the 

PSP  and  TSP 

courses 

The  PG  Training  Manager  is 
responsible  for  maintaining 
these  records. 

Process  Group 
roles  and  re¬ 
sponsibilities 

OT  SP  2.3 

Assess  the  effectiveness 
of  the  organization’s 
training  program. 

Form  TRNSUR,  the 
training  surveys  and 
their  analysis  (form 
SUMTRNS) 

PSP  course  feedback 
forms,  TSP  launch 
evaluation  forms,  TSP 
Checkpoint  results, 

PM  results 

The  PG  Training  Manager  is 
responsible  for  ensuring  that 
the  training  is  assessed  and 
appropriate  actions  taken. 

OT  GG  2 

The  process  is  institutio¬ 
nalized  as  a  managed 
process. 

OT  GP 

2.1 

Establish  and  maintain 
an  organizational  policy 
for  planning  and  perform¬ 
ing  the  organizational 
training  process. 

Policy  will  be  specific 
to  each  organization. 

This  issue  to  be  addressed 
by  the  Implementation 

Guide. 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  Organiza¬ 
tional  Training 
Description 

Direct  Artifact 

Guidance 

Process  Group 
roles  and  re¬ 
sponsibilities 

OTGP 

2.2 

Establish  and  maintain 
the  plan  for  performing 
the  organizational  train¬ 
ing  process. 

The  PG  training  man¬ 
ager  will  establish  and 
maintain  a  TSP  plan 
for  performing  the 
Organizational  Train¬ 
ing  activities. 

The  organizational  training 
activities  are  mainly  the 
responsibility  of  the  PG 
Training  Manager;  however, 
others  may  contribute.  The 
plan  will  be  a  TSP  plan, 
including  the  necessary 
activities  and  work  products. 

Process  Group 
roles  and  re¬ 
sponsibilities 

OTGP 

2.3 

Provide  adequate  re¬ 
sources  for  performing 
the  organizational  train¬ 
ing  process,  developing 
the  work  products,  and 
providing  the  services  of 
the  process. 

PG  Training  Manag¬ 
er’s  TSP  plan 

Training  plan 

Either  external  (SEI  or  SEI 
Partner)  or  internal  (SEI- 
authorized)  instructors  are 
specified  by  the  TSP  Intro¬ 
duction  Strategy;  see  the 
training  matrix. 

Training  records  document 
instructor  resources,  and 
training  preparation  mate¬ 
rials  document  room  and 
computer  resource  needs. 

Process  Group 
roles  and  re¬ 
sponsibilities 

OTGP 

2.4 

Assign  responsibility  and 
authority  for  performing 
the  process,  developing 
the  work  products,  and 
providing  the  services  of 
the  organizational  train¬ 
ing  process. 

The  PG  plan  will  have 
a  Training  Manager 
role  assigned. 

LOGTRNM, 

TRNM 

OTGP 

2.5 

Train  the  people  perform¬ 
ing  or  supporting  the 
organizational  training 
process  as  needed. 

Training  records  for 

PG  Training  Manager 
and  others  supporting 
training  should  be 
documented  in  the 
individual’s  training 
records.  The  need  for 
such  training  should 
be  captured  in  the 
training  matrix 
(TRNM). 

The  PG  Training  Manager 
may  have  specific  training 
requirements  that  will  be 
documented  in  the  training 
matrix. 

Process  Group 
roles  and  re¬ 
sponsibilities, 

TRN 

OTGP 

2.6 

Place  designated  work 
products  of  the  organiza¬ 
tional  training  process 
under  appropriate  levels 
of  control. 

The  training  work 
products  will  be  confi¬ 
guration  items  in  the 

CM  system. 

See  CM. 

It  is  the  responsibility 
of  the  Training  Man¬ 
ager  to  determine  the 
appropriate  configura¬ 
tion  controls  needed 
to  maintain  all  training 
products. 

The  PG  Training  Manager 
will  help  define  the  appropri¬ 
ate  handling  of  organiza¬ 
tional  training  work  products 
using  the  CM  procedures.  It 
is  assumed  that  course  and 
training  material  will  use  the 
CM  procedures  and  that 
training  records  will  be 
placed  under  informal  confi¬ 
guration  control  similar  to 
those  items  called  out  in  the 
project  notebook  specifica¬ 
tion. 

TRNM,  SRAM, 
RSIM 

OTGP 

2.7 

Identify  and  involve  the 
relevant  stakeholders  of 
the  organizational  train¬ 
ing  process  as  planned. 

Training  Matrix,  train¬ 
ing  plan,  TSP  PG 
Training  Manager 
plan 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  Organiza¬ 
tional  Training 
Description 

Direct  Artifact 

Guidance 

WEEK, 

STATUS 

OTGP 

2.8 

Monitor  and  control  the 
organizational  training 
process  against  the  plan 
for  performing  the 
process  and  take  appro¬ 
priate  corrective  action. 

The  PG  Training 
Manager  plan  is  mo¬ 
nitored  and  controlled 
using  the  same  PMC 
procedures  as  all  the 
TSP  plans. 

The  PG,  including  the  PG 
Manager,  will  review  and 
monitor  the  plans  weekly. 

CHECKPOINT 

OTGP 

2.9 

Objectively  evaluate 
adherence  of  the  organi¬ 
zational  training  process 
against  its  process  de¬ 
scription,  standards,  and 
procedures;  address 
noncompliance. 

PG  Checkpoint  report 
Noncompliances  are 
listed  in  the  report 
and  reviewed  and 
tracked  to  closure  by 
the  TSP  Coach  as¬ 
signed  to  coach  the 

PG. 

The  Process  Group  is  a  TSP 
team.  As  such,  it  has  a 
coach,  launch,  plan,  and  a 
workbook.  The  work  of  the 

PG  will  have  the  same 
Checkpoint  performed  as 
the  projects.  This  includes 
review  of  the  forms, 
processes,  and  work  prod¬ 
ucts  associated  with  train¬ 
ing. 

STATUS 

OTGP 

2.10 

Review  the  activities, 
status,  and  results  of  the 
organizational  training 
process  with  higher  level 
management ;  resolve 
issues. 

The  PG  plan,  as  with 
all  TSP  plans,  will  be 
regularly  reviewed 
with  management. 

Process  Group 
roles  and  re¬ 
sponsibilities 

OTGP 

3.1 

Establish  and  maintain 
the  description  of  a  de¬ 
fined  organizational  train¬ 
ing  process. 

The  OSSP  will  in¬ 
clude  the  organiza¬ 
tional  training 
process. 

The  PG  Training  Manager 
working  with  the  PG  Support 
Manager,  PG  Process  Man¬ 
ager  and  PG  Process  Asset 
and  Data  Repository  Man¬ 
ager  will  establish  and  main¬ 
tain  the  description  of  the 
organization’s  defined  train¬ 
ing  process. 

Process  Group 
roles  and  re¬ 
sponsibilities 

OTGP 

3.2 

Collect  work  products, 
measures,  measurement 
results,  and  improvement 
information  derived  from 
planning  and  performing 
the  OT  process  to  sup¬ 
port  the  future  use  and 
improvement  of  the  or¬ 
ganization’s  processes 
and  process  assets. 

The  Process  Asset 
Library  and  asso¬ 
ciated  collection  me¬ 
chanisms 

The  organizational 
infrastructure  (includ¬ 
ing  the  PAL  and  the 
measurement  reposi¬ 
tory)  is  developed  by 
the  Process  Group; 
see  OPF,  OPD. 

The  TSP+  has  been  ex¬ 
panded  to  include  a  PG 
Process  Asset  and  Data 
Repository  Manager. 
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3.4  Support  Processes 

3.4.1  Configuration  Management  (CM) 


The  following  table  lists  the  elements  of  the  Configuration  Management  (CM)  process  area  em¬ 
ployed  in  the  AIM  approach. 


TSP/PSP 

CMMI 

CMMI  PA:  CM  Direct  Artifact 

Guidance 

Reference 

Feature 

Configuration  Man- 

agement  Description 

CM  SG  1 

Baselines  of  identified 
work  products  are 
established. 

CM  SP  1.1 

CM  SP  1.2 

Identify  the  configura¬ 
tion  items,  compo¬ 
nents,  and  related 
work  products  that  will 
be  placed  under  confi¬ 
guration  management. 

Filled-in  forms  CIBPS  and 

LOGCI  (  Log  of  Configuration 
items) 

Critical  items  identified  during 
LAU3 and  LAU6 

Scripts  CM  and  CMR 
define  creating  and  re¬ 
viewing  the  CIBPS  with 
individual  items  logged  in 
LOGCI.  Also,  the  PREPT 
checklist  should  call  for 
identifying  existing  arti¬ 
facts,  especially  those 
already  under  CM. 

Establish  and  maintain 
a  configuration  man¬ 
agement  and  change 
management  system 
for  controlling  work 
products. 

Script  CM  and  associated 
forms  and  scripts  establish  a 

CM  system.  During  prepara¬ 
tion  (checklist  PREPT)  Sup¬ 
port  Manager  ensures  that  it  is 
adequate  for  team  needs. 

Script  CM  and  associated 
forms  and  scripts  estab¬ 
lish  a  CM  system.  During 
preparation  (checklist 
PREPT),  the  Support 
Manager  ensures  that  it  is 
adequate  for  team  needs. 

CM  SP  1.3 

Create  or  release 
baselines  for  internal 
use  and  for  delivery  to 
the  customer. 

Script  TEST3  calls  for  creating 
a  release  from  system  test  to 
the  customer.  Filled-in  forms 

CIR  should  document  release 
requests.  Forms  CIBPS  should 
document  all  baselines,  includ¬ 
ing  releases. 

Script  TEST3  calls  for 
creating  a  release  from 
system  test  to  the  cus¬ 
tomer.  Filled-in  forms  CIR 
should  document  release 
requests.  Forms  CIBPS 
should  document  all  base¬ 
lines,  including  releases. 

CM  SG  2 

Changes  to  the  work 
products  under  confi¬ 
guration  management 
are  tracked  and  con¬ 
trolled. 

CM  SP  2.1 

Track  change  requests 
for  the  configuration 
items. 

Filled-in  CCR  forms  (ref.  Intro¬ 
duction  to  the  Team  Software 
Process,  App.  B) 

Filled-in  CCRs  and  LOGCCR 
documents  change  requests  to 
controlled  items 

Filled-in  CCR  forms  (ref. 
Introduction  to  the  Team 
Software  Process,  App.  B) 
Filled-in  CCRs  and 

LOGCCR  documents 
change  requests  to  con¬ 
trolled  items. 

Filled-in  forms  CCR  (es¬ 
pecially  approval  section) 
and  new  entries  in  form 
CIBPS  document  changes 
made  to  configuration 
items.  CCB  minutes  may 
capture  additional  relevant 
information. 

CM  SP  2.2 

Control  changes  to  the 
configuration  items. 

Filled-in  forms  CCR  (especially 
approval  section)  and  new 
entries  in  form  CIBPS  docu¬ 
ment  changes  made  to  confi¬ 
guration  items.  CCB  minutes 
may  capture  additional  rele¬ 
vant  information. 

CM  SG  3 

Integrity  of  baselines  is 
established  and  main¬ 
tained. 
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TSP/PSP 

CMMI 

CMMI  PA:  CM  Direct  Artifact 

Guidance 

Reference 

Feature 

Configuration  Man¬ 

agement  Description 

CM  SP  3.1 

Establish  and  maintain 
records  describing 
configuration  items. 

Filled-in  forms  CIBPS,  LOGCI, 
LOGCCR 

CM  SP  3.2 

Perform  configuration 
audits  to  maintain 
integrity  of  the  configu¬ 
ration  baselines. 

Filled-in  forms  LOGCI  showing 

Cl  audit  status,  INV  showing 
discrepancies,  and  the  CM 
audit  summary  presented  in 
the  management  STATUS 
briefing 

CM  GG  3 

The  process  is  institu¬ 
tionalized  as  a  defined 
process. 

CM  GP  2.1 

Establish  and  maintain 
an  organizational  poli¬ 
cy  for  planning  and 
performing  the  confi¬ 
guration  management 
process. 

No  policies  in  TSP 

This  issue  to  be  ad¬ 
dressed  by  the  Implemen¬ 
tation  Guide. 

CM  GP  2.2 

Establish  and  maintain 
the  plan  for  performing 
the  configuration  man¬ 
agement  process. 

Script  SCM  and  the  support 
role  description  and  implemen¬ 
tation  in  Support  Manager’s 
TASK  plan 

Execution  of  scripts  CM/CMR 
and  checklist  PREPT  as  re¬ 
flected  in  the  Support  Manag¬ 
er’s  and  other  team  members’ 
TASK  plans 

CM  GP  2.3 

Provide  adequate 
resources  for  perform¬ 
ing  the  configuration 
management  process, 
developing  the  work 
products,  and  provid¬ 
ing  the  services  of  the 
process. 

Support  role  is  assigned  dur¬ 
ing  LAU2.  Needed  CM  tools 
are  identified  during  LAU3  step 

8  and  recorded  on  INV.  These 
items  are  planned  for  during 
LAU4  and  LAU6. 

Checklist  PREPT  shows  prep¬ 
aration  for  tools  and  storage 
resources;  form  INV  will  record 
any  additional  items  needed 
by  the  team. 

CM  GP  2.4 

Assign  responsibility 
and  authority  for  per¬ 
forming  the  process, 
developing  the  work 
products,  and  provid¬ 
ing  the  services  of  the 
configuration  man¬ 
agement  process. 

Support  role  is  assigned  in 

LAU2  and  has  responsibility 
for  CM  activities  and  re¬ 
sources. 

Support  Manager  role  as  do¬ 
cumented  by  filled-in  ROLE 
matrix;  CM  plan  as  docu¬ 
mented  in  the  Support  Manag¬ 
er  and  other  team  members’ 
plans,  especially  by  TASK 
entries  for  CCB  meetings 
Filled-in  form  CIBPS  shows  Cl 
owners,  form  LOGCCR  shows 
product  owners 

Resolve  difference  (if  any) 
between  Cl  owners  and 
product  owners. 
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Direct  Artifact 


Guidance 


TS  P/PSP 
Reference 


CMMI  CMMI  PA:  CM 

Feature  Configuration  Man¬ 


agement  Description 


CM  GP  2.5 

Train  the  people  per¬ 
forming  or  supporting 
the  configuration  man¬ 
agement  process  as 
needed. 

Support  Manager  role  men¬ 
tioned  briefly  in  TSP  Coach 
training 

Support  Manager  training  is 
on-the-job  by  the  TSP  Coach 
per  checklist  PREPT.  Addi¬ 
tional  training  needed  by  team 
members  should  be  captured 
on  form  INV. 

CM  training  in  PSP  and 

TSP  is  minimal. 

CM  GP  2.6 

Place  designated  work 
products  of  the  confi¬ 
guration  management 
process  under  appro¬ 
priate  levels  of  control. 

Script  SCM,  form  CCR,  role 
manager  description,  plus  lists 
of  CIs 

Filled-in  forms  CIBPS,  LOGCI, 
CCR,  LOGCCR,  and  CIR 
under  appropriate  configura¬ 
tion  controls 

CM  process  and  tools 
generally  will  be  organiza¬ 
tion  specific 

There  is  a  need  for  the 
major  CM  scripts  (as  now 
defined)  and  filled-in  arti¬ 
facts  under  appropriate 
configuration  control  (e.g., 
forms  CIBPS,  LOGCI, 

CCRs,  LOGCCR,  CIR  and 
CM  audit  results)  or  the 
equivalent. 

CM  GP  2.7 

Identify  and  involve  the 
relevant  stakeholders 
of  the  configuration 
management  process 
as  planned. 

Support  Manager  reports  to 
team  weekly  on  CM  activities 
(WEEK  minutes) 

Filled-in  form  RSIM  identifies 
relevant  stakeholders  for  forms 
CMBPRS,  CIR,  CMAUDIT, 
LOGCCR,  LOGCI 

Weekly  status  of  relevant  role 
managers  demonstrates  in¬ 
volvement. 

CM  GP  2.8 

Monitor  and  control  the 
configuration  man¬ 
agement  process 
against  the  plan  for 
performing  the  process 
and  take  appropriate 
corrective  action. 

The  Support  role  reports  to  the 
team  weekly  on  significant  CM 
activities. 

Artifacts  from  CM  activities 
(records  of  new  and  changed 
baselines,  builds  made,  confi¬ 
guration  audits,  etc. 

The  CM  forms  and  TASK  en¬ 
tries  for  new  CM  scripts,  as 
well  as  weekly  support  man¬ 
ager  reports 

CM  GP  2.9 

Objectively  evaluate 
adherence  of  the  con¬ 
figuration  management 
process  against  its 
process  description, 
standards,  and  proce¬ 
dures;  address  non- 
compliance. 

The  TSP  Coach  reviews  sup¬ 
port  role  activities  and  docu¬ 
ments  findings  in  TSP  Check¬ 
point  results. 

Results  of  relevant  Support 
Manager  Checkpoint  activities 
(see  CM  items  in  Questions 
section  of  Support  Manager 
role  specification),  and  filled-in 
CM  forms  and  logs 

Checkpoints  produce  an 
artifact  showing  that  role 
manager  questions  were 
evaluated  and  appropriate 
actions  taken  for  resolu¬ 
tion  where  necessary. 

CM  GP 

2.10 

Review  the  activities, 
status,  and  results  of 
the  configuration  man¬ 
agement  process  with 
higher  level  manage¬ 
ment  ;  resolve  issues. 

Management  STATUS  report 
section  showing  configuration 
audit  results,  including  discre¬ 
pancies  not  otherwise  resolved 
from  forms  ITL  (Issue/Risk 
Tracking  Log) 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  CM 
Configuration  Man¬ 
agement  Description 

Direct  Artifact 

Guidance 

CM  GP  3.1 

Establish  and  maintain 
the  description  of  a 
defined  configuration 
management  process. 

Script  SCM  and  support  role 
description 

CM  GP  3.2 

Collect  work  products, 
measures,  measure¬ 
ment  results,  and  im¬ 
provement  information 
derived  from  planning 
and  performing  the 
configuration  man¬ 
agement  process  to 
support  the  future  use 
and  improvement  of 
the  organization’s 
processes  and 
process  assets. 

Standard  postmortem  results 
from  enacting  script  PM 

Project  notebook 
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3.4.2  Process  and  Product  Quality  Assurance  (PPQA) 

The  following  table  lists  the  elements  of  the  Process  and  Product  Quality  Assurance  (PPQA) 
process  area  employed  in  the  AIM  approach. 


TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA: PPQA  Process 
and  Product  Quality 
Assurance 

Direct  Artifact 

Guidance 

PPQA  SG 

1 

Adherence  of  the  per¬ 
formed  process  and  asso¬ 
ciated  work  products  and 
services  to  applicable 
process  descriptions,  stan¬ 
dards,  and  procedures  is 
objectively  evaluated. 

The  TSP+  approach  to 
process  adherence  centers 
on  the  Coach  role  and  the 
Checkpoint.  Objectivity  is 
achieved  by  independence 
of  the  Coach  from  the 
project,  and  the  review  of 
forms  and  scripts  marked  as 
“R,”  for  “responsible,”  in  the 
RSIM  (Relevant  Stakeholder 
Involvement  Matrix). 

An  example  Checkpoint 
report  format  is  provided 
showing  how  the  forms  and 
scripts  from  the  RSIM  can 
be  used  as  a  checklist  for 
PPQA  purposes. 

The  PG  Process  Manager 
role  is  to  ensure  objectivity 
and  conformity  of  the 
project’s  process  managers 
in  objectively  evaluating 
process  conformance. 

Coach  roles 
and  responsibil¬ 
ities 

CYCLE, 
CHECKPOINT, 
CHECKTMDR, 
Checkpoint 
report  guideline 

PPQA  SP 
1.1 

Objectively  evaluate  the 
designated  performed 
processes  against  the 
applicable  process  descrip¬ 
tions,  standards,  and  pro¬ 
cedures. 

TSP+  checkpoint 
results 

Postmortem  report 

See  the  example  Check¬ 
point  report.  The  Checkpoint 
includes  a  quantitative  re¬ 
view  of  individual  and  team 
performance  as  well  as  a 
process  evaluation. 

In  the  Checkpoint  script, 
step  5  (role  review)  and  step 

6  (process  review)  in  con¬ 
junction  with  discussions 
from  step  3  (team  review) 
and  step  7  (individual  dis¬ 
cussions)  are  the  main  ve¬ 
hicle  for  objective  evaluation 
of  processes. 

It  is  important  to  note  that 
many  of  the  CMMI  practices 
(especially  generic  practic¬ 
es)  are  accomplished  by  the 
role  assignments  in  the 

TSP+.  Care  was  taken  to 
ensure  that  there  would  be 
comprehensive  coverage  for 
CMMI  generic  practice  2.9 
across  the  all  the  Process 
Areas  by  incorporating  role 
reviews. 
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TSP/PSP 

CMMI 

CMMI  PA: PPQA  Process 

Direct  Artifact 

Guidance 

Reference 

Feature 

and  Product  Quality 
Assurance 

INS,  DEV, 

MAINT 

PPQA  SP 
1.2 

Objectively  evaluate  the 
designated  work  products 
and  services  against  the 
applicable  process  descrip¬ 
tions,  standards,  and  pro¬ 
cedures. 

Defect  logs  of  per¬ 
sonal  reviews  of 
designs  and  code, 
inspection  reports, 
unit  test  results 

Personal  reviews  are  done 
by  the  producer  of  an  arti¬ 
fact;  inspections  are  per¬ 
formed  by  their  peers.  On  a 
typical  TSP  project,  all  code, 
designs,  requirements,  and 
externally  distributed  docu¬ 
ments  are  inspected. 

Defect  logging,  quality  plan¬ 
ning,  and  analysis  are  hall¬ 
marks  of  TSP. 

PPQA  SG 

2 

Noncompliance  issues  are 
objectively  tracked  and 
communicated,  and  resolu¬ 
tion  is  ensured. 

Defects  are  logged  and 
tracked  to  closure  in  form 
LOGD.  Process  noncom¬ 
pliances  are  logged  in  the 
Checkpoint  report  and 
tracked  in  the  Checkpoint 
process. 

WEEK, 

STATUS, 

CHECKPOINT, 

CYCLE 

PPQA  SP 
2.1 

Communicate  quality  is¬ 
sues  and  ensure  resolution 
of  noncompliance  issues 
with  the  staff  and  manag¬ 
ers. 

Defect  logs,  issues 
in  ITL  (IRTL  in  TSP 
Excel  workbook), 

TSP  Checkpoint 
results 

Issues  are  reported 
to  management  in 
the  STATUS  report. 

Quality  issues  are  commu¬ 
nicated  to  staff  and  mangers 
by  the  Issue/Risk  Tracking 
log,  the  STATUS  report  in 
regular  management  meet¬ 
ings  and  weekly  team  meet¬ 
ings,  as  well  as  by  the  pres¬ 
entation  of  Checkpoint 
results.  See  the  Quality 
manager  role  and  Process 
manager  role. 

PPQA  SP 
2.2 

Establish  and  maintain 
records  of  the  quality  as¬ 
surance  activities. 

Defect  logs,  ITL, 
Checkpoint  results 

PPQA  GG 

2 

The  process  is  institutiona¬ 
lized  as  a  managed 
process. 

PPQA  GP 
2.1 

Establish  and  maintain  an 
organizational  policy  for 
planning  and  performing 
the  process  and  product 
quality  assurance  process. 

No  policies  in  TSP+ 

There  are  no  policies  in 

TSP.  This  issue  will  be  ad¬ 
dressed  by  the  Implementa¬ 
tion  Guide. 

LAU, 

TASK 

PPQA  GP 

2.2 

Establish  and  maintain  the 
plan  for  performing  the 
process  and  product  quali¬ 
ty  assurance  process. 

Coach  TSP  plan  and 
individual  TSP  plans 
including  role  tasks 

Individual  plans  have  tasks 
for  the  assigned  roles.  The 
Coach  will  have  a  separate 
TSP  plan  for  coaching  and 
Checkpoint  activities.  Re¬ 
views,  inspections,  and  the 
Checkpoint  will  be  sche¬ 
duled  and  tasks  in  the  re¬ 
spective  TSP  plan,  TSP 
Checkpoints  and  coaching 
plan  established  (LAU8). 

See  the  Process,  quality, 
and  test  manager  role 
(LAU2) 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA: PPQA  Process 
and  Product  Quality 
Assurance 

Direct  Artifact 

Guidance 

LAU2, 

ROLE 

PPQA  GP 
2.3 

Provide  adequate  re¬ 
sources  for  performing  the 
process  and  product  quali¬ 
ty  assurance  process, 
developing  the  work  prod¬ 
ucts,  and  providing  the 
services  of  the  process. 

TSP  Coach,  Team 
Leader,  and  several 
roles  (process, 
quality,  and  test)  are 
assigned  to  these 
functions  in  LAU2 
form  ROLE  (role 
matrix). 

Individual  plans  have  tasks 
for  assigned  roles.  Individual 
plans  have  tasks  for  re¬ 
views,  inspections,  and 
testing.  The  Coach’s  plan 
has  tasks  for  the  Check¬ 
point. 

Role  specifica¬ 
tions,  RSIM, 
LAU2,  SRAM 

PPQA  GP 

2.4 

Assign  responsibility  and 
authority  for  performing  the 
process,  developing  the 
work  products,  and  provid¬ 
ing  the  services  of  the 
process  and  product  quali¬ 
ty  assurance  process. 

TSP  Coach,  Team 
Leader,  and  several 
roles  (process, 
quality,  and  test)  are 
assigned  to  these 
functions  in  LAU2 
(role  matrix). 

Role  descriptions  (including 
that  of  the  Coach)  and  re¬ 
sulting  plans  show  clear 
responsibility  and  authority. 

LOGTRNM, 

TRNM 

PPQA  GP 

2.5 

Train  the  people  perform¬ 
ing  or  supporting  the 
process  and  product  quali¬ 
ty  assurance  process  as 
needed. 

PSP  training  covers 
how  to  perform 
checklist-based 
reviews.  TSP  coach 
training  covers 
Checkpoints  and 
inspections. 

The  Implementation  Guide 
will  provide  guidance. 

The  Implementation  Guide 
will  include  QA  guidance  for 
the  Process  Group. 

PREPT 

Support  Man¬ 
ager  role  speci¬ 
fication 

PPQA  GP 

2.6 

Place  designated  work 
products  of  the  process 
and  product  quality  assur¬ 
ance  process  under  ap¬ 
propriate  levels  of  control. 

Project  NOTEBOOK 
contains  ITL,  defect 
logs,  and  Check¬ 
point  reports. 

The  Support  Man¬ 
ager  is  responsible 
for  developing  a 
plan  for  the  man¬ 
agement  of  all 
project  data  identi- 

Informal  configuration  man¬ 
agement  may  be  considered 
appropriate  for  all  items 
identified  in  the  specification 
NOTEBOOK.  It  is  up  to  the 
team  to  determine  where 
and  how  these  items  will  be 
stored  and  how  they  will 
have  access  to  them  during 
launch  preparation. 

tied  in  the  specifica¬ 
tion  NOTEBOOK. 


RSIM  SRAM 


PPQA  GP 
2.7 


Identify  and  involve  the 
relevant  stakeholders  of 
the  process  and  product 
quality  assurance  process 
as  planned. 


This  is  usually  ac¬ 
complished  by  de¬ 
signating  a  specific 
project  folder  on  a 
drive  or  using  a 
web-based  file¬ 
sharing  system. 
Levels  of  control  are 
handled  by  setting 
access  permissions. 

Forms  RSIM, 

SRAM,  ROLE 


The  RSIM  lists  the  respon¬ 
sible  party  for  each  script 
and  form. 

See  PPQA  forms  LOGD, 

CHECKPOINT, 

CHECKMDR, 


The  Coach  is  clearly  identi¬ 
fied  and  responsibilities  for 
PPQA  activities  including 
the  checkpoint  are  listed. 
Management,  the  Team 
Leader,  and  the  team,  es¬ 
pecially  certain  roles,  have 
activities  that  are  reflected  in 
the  plan,  tracking  data,  and 
test  and  Checkpoint  results. 
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TSP/PSP 

CMMI 

CMMI  PA: PPQA  Process 

Direct  Artifact 

Guidance 

Reference 

Feature 

and  Product  Quality 
Assurance 

PPQA  GP 
2.8 


Monitor  and  control  the 
process  and  product  quali¬ 
ty  assurance  process 
against  the  plan  for  per¬ 
forming  the  process  and 
take  appropriate  corrective 
action. 


Individual  plans,  the 
team  plan,  and  the 
Coach  plan  are 
monitored  and  con¬ 
trolled  through  the 
normal  TSP  PMC 
process. 

Within  the  Process 
Group,  the  role  of 
Coaching  Manager 
is  responsible  for 
performing  oversight 
for  the  coaching 
activity.  This  in¬ 
cludes  monitoring 
and  controlling  the 
Checkpoint. 

The  status  of  activi¬ 
ties  is  reflected  in 
the  plan,  tracking 
data,  SUMMARY 
presentations,  and 
test  and  checkpoint 
results. 


The  activities  for  SP  1 .2  are 
the  reviews,  inspections, 
and  tests  that  are  tasks  in 
the  appropriate  plan.  These 
are  monitored  and  con¬ 
trolled  using  the  same  PMC 
process  used  for  all  TSP 
plans. 

The  activities  for  SP  1 .1  are 
mainly  focused  on  the 
Coach’s  Checkpoint  activi¬ 
ties.  These  are  reflected  in 
the  Coach’s  plan  and  moni¬ 
tored  using  the  same  PMC 
process  used  for  all  TSP 
plans. 


Plans  for  individual 
reviews,  formal 
inspections,  unit 
tests,  and  Check¬ 
points  comprise  the 
plans,  monitored 
through  weekly 
meeting  reports, 
management 
STATUS  reports, 
and  Checkpoint 
reports. 


Process  Group 
roles  and  re¬ 
sponsibilities 


PPQA  GP 
2.9 


Objectively  evaluate  adhe¬ 
rence  of  the  process  and 
product  quality  assurance 
process  against  its  process 
description,  standards,  and 
procedures;  address  non- 
compliance. 


Within  the  Process 
Group,  the  role  of 
Coaching  Manager 
is  responsible  for 
performing  oversight 
for  the  coaching 
activity.  This  in¬ 
cludes  objective 
evaluation  of  the 
Checkpoint  activities 
and  work  products. 
The  PG  Coaching 
Manager  will  devel¬ 
op  reporting  and 
tracking  mechan¬ 
isms. 


The  PG  Coaching  Manager 
is  responsible  for  objective 
evaluation  of  the  coaches 
and  the  Checkpoint  (PPQA) 
activities  and  work  products 
The  PG  Process  Manager  is 
responsible  for  ensuring  that 
each  Project  Process  Man¬ 
ager  performs  objective 
evaluation  of  the  project’s 
processes. 
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TSP/PSP 

CMMI 

CMMI  PA: PPQA  Process 

Direct  Artifact 

Guidance 

Reference 

Feature 

and  Product  Quality 
Assurance 

STATUS 

CHECKPOINT 

PPQA  GP 
2.10 

Review  the  activities,  sta¬ 
tus,  and  results  of  the 
process  and  product  quali¬ 
ty  assurance  process  with 
higher  level  management ; 
resolve  issues. 

TSP  Checkpoint 
results  and  quarterly 
management  re¬ 
views  (STATUS 
presentations)  of 
project  issues 
STATUS  reports 
specifically  address 
QA  issues 

Checkpoint  results 
presented  to  man¬ 
agement 

The  Checkpoint  has  built-in 
management  review  in  its 
process  (script  Checkpoint, 
step  10). 

Process  Group 
roles  and  re¬ 
sponsibilities 

PPQA  GP 

3.1 

Establish  and  maintain  the 
description  of  a  defined 
process  and  product  quali¬ 
ty  assurance  process. 

Checkpoint  scripts 
(process)  will  be  in 
the  OSSP. 

The  PG  role  of  Process 
Manager  is  responsible  for 
establishing  and  maintaining 
the  OSSP. 

Process  Group 
roles  and  re¬ 
sponsibilities 

PPQA  GP 

3.2 

Collect  work  products, 
measures,  measurement 
results,  and  improvement 
information  derived  from 
planning  and  performing 
the  process  and  product 
quality  assurance  process 
to  support  the  future  use 
and  improvement  of  the 
organization’s  processes 
and  process  assets. 

Process  Asset  Li¬ 
brary  and  Data  re¬ 
pository 

TSP  Checkpoint 
results,  inspection 
reports,  unit  test 
results,  issues  in  ITL 
(IRTL  in  the  TSP 

Excel  tool),  project 
management  arti¬ 
facts  reflecting  QA 
activities  and  stored 
in  the  project 
NOTEBOOK. 

The  PG  role  of  Process 

Asset  and  Data  Repository 
Manager  is  responsible  for 
establishing  and  maintaining 
the  organization’s  Process 
Asset  Library  and  Data  Re¬ 
pository. 
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3.4.3  Measurement  and  Analysis  (M&A) 

There  is  a  sophisticated  measurement  and  analysis  system  incorporated  into  the  TSP+.  The  Im¬ 
plementation  guide  will  describe  this  system  and  how  it  should  be  adapted  to  satisfy  the  CMMI 
practices 


TSP/PSP  CMMI  CMMI  PA:  Measurement  and  Direct  Artifact 

Reference  Feature  Analysis  (MA)  Description 

Guidance 

MA  SG  1 

Measurement  objectives  and 
activities  are  aligned  with 
identified  information  needs 
and  objectives. 

MASP 

1.1 


MASP 

1.2 


MA  SP 
1.3 


Establish  and  maintain  mea¬ 
surement  objectives  that  are 
derived  from  identified  infor¬ 
mation  needs  and  objectives. 


Specify  measures  to  address 
the  measurement  objectives. 


Specify  how  measurement 
data  will  be  obtained  and 
stored. 


Standard  Measure¬ 
ment  objectives  are 
embedded  in  the 
TSP. 

Management  can 
add  or  modify  objec¬ 
tives  in  the  PG 
(Process  Group) 
launch  or  the  project 
launch  in  meeting  1. 
Individual  and  con¬ 
solidated  workbooks 
TSP  WEEK  Form 
TSP  NOTEBOOK 
Specification 
TSP  STATUS  Speci¬ 
fication 


Instructions  for  forms 
SUMS,  LOGT, 

LOGD,  TASK,  and 
SCHED 

TSP-related  meas¬ 
ures  shall  be  col¬ 
lected  and  stored  in 
the  workbooks. 
Examples  of  TSP- 
related  measures 
collected  in  the 
workbooks  are 
earned  value,  time 
on  tasks,  defects  by 
phase,  planned  vs. 
actual  hours,  and 
product  size. 


Forms  SUMS, 

LOGT,  LOGD, 

TASK,  and  SCHED. 
Records  of  individual 
decisions  about 
project  NOTEBOOK 
storage. 


Measurement  objectives  of 
the  TSP  are  known  and 
extensively  discussed  in  the 
literature.  The  consolidated 
workbook  shall  be  consi¬ 
dered  the  project  plan,  and 
the  individual  workbooks,  the 
individual  plans.  The  mea¬ 
surement  objectives  are 
inherent  to  the  TSP  process. 
Management  may  identify 
additional  objectives  during 
the  launch/re-launch  meet¬ 
ing  1.  In  addition,  manage¬ 
ment  can  give  direction  to 
PG  to  add  or  modify  mea¬ 
surement  objectives. 

TSP  utilizes  four  basic 
measures  (estimated  and 
actual  values  for  product  or 
component  size,  time  in 
phase,  defects  in¬ 
jected/found  by  phase,  and 
completion  date) 

Familiarity  with  the  TSP 
embedded  measurement 
system,  which  is  very  helpful 
to  appraisers,  is  well  docu¬ 
mented  in  the  PSP/TSP 
books 


Data  collection  and  storage 
mechanisms,  specified  in  the 
plan  for  each  project. 

Data  collected  in  the  individ¬ 
ual  workbooks. 

Consolidated  workbook  of 
weekly  individual  data  stored 
in  a  team  location  with  ap¬ 
propriate  configuration  man¬ 
agement  controls. 
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TSP/PSP  CMMI  CMMI  PA:  Measurement  and  Direct  Artifact  Guidance 

Reference  Feature  Analysis  (MA)  Description 

MA  SP 

1.4 

Specify  how  measurement 
data  will  be  analyzed  and 
reported. 

Individual  and  con¬ 
solidated  workbooks, 
particularly  charts 
and  graphs 

Script  PM  and 

WEEK,  forms 

WEEK,  SUMP, 

SUMQ,  and  the 
NOTEBOOK  and 
STATUS  specifica¬ 
tions 

The  Chart  Controls  portion 
of  the  PROJECT  Tab  in  the 
electronic  TSP  workbooks 
provides  charts  and  analysis 
of  the  measure. 

MASG2 

Measurement  results,  which 
address  identified  information 
needs  and  objectives,  are 
provided. 

MA  SP 

2.1 

Obtain  specified  measure¬ 
ment  data. 

Individual  and  con¬ 
solidated  workbooks 

Filled-in  forms 

SUMS,  LOGT, 

LOGD,  and  TASK 

Data  collected  by  practition¬ 
ers  in  their  individual  work¬ 
books 

One  of  the  purposes  of  the 
planning  manager  role  is  to 
ensure  that  the  members  of 
the  team  follow  the  process 
in  collecting  and  reporting 
actual  data  in  real  time.  (The 
coach  plays  a  role  here  as 
well.) 

In  general  actuals  shall  be 
compared  to  planned  to  see 
if  the  variance  is  within  ac¬ 
ceptable  tolerance. 

The  data  analysis  completed 
in  support  of  the  projects 
shall  be  in  the  workbooks, 
the  checkpoints  and 
cycle/project  postmortem. 
The  analysis  reported  during 
the  weekly  status  meetings 
with  management.  In  addi¬ 
tion  to  the  information  pre¬ 
sented  off  the  PROJECT 
Tab  of  the  workbook,  the 
project  established  goals 
shall  also  be  reported. 

Generally,  all  data  collected 
(both  base  and  derived),  the 
resulting  analysis  as  re¬ 
ported  to  management  shall 
be  stored  in  accordance  with 
the  project  plan  or  some 
organizational  directive. 

The  data  is  stored  and  daily 
backups  of  the  server  files 
are  maintained  by  the  sys¬ 
tem  administrators  according 
to  good  configuration  man¬ 
agement  practices. 


MASP 

2.2 


Analyze  and  interpret  mea¬ 
surement  data. 


MA  SP 
2.3 


Manage  and  store  measure¬ 
ment  data,  measurement 
specifications,  and  analysis 
results. 


Analysis  in  individual 
and  consolidated 
workbooks 
Management  pres¬ 
entations 
Checkpoint  and 
postmortem  analysis 
Forms  WEEK  (and 
any  associated 
charts  and  graphs), 
SUMP,  SUMQ,  and 
actual  NOTEBOOK 
data  and  STATUS 
presentations. 


Individual  and  team 
workbooks  including 
weekly  summary 
data  (form  WEEK), 
PM  results,  and  of 
actual  NOTEBOOK 
and  STATUS  pres¬ 
entations. 
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TSP/PSP 

Reference 

CMMI 

Feature 

CMMI  PA:  Measurement  and 
Analysis  (MA)  Description 

Direct  Artifact 

Guidance 

MASP 

2.4 

Report  results  of  measure¬ 
ment  and  analysis  activities  to 
all  relevant  stakeholders. 

PM  results,  and 
minutes  for  weekly 
meetings,  STATUS 
presentations,  and 
any  other  stakehold¬ 
er  meetings  at  which 
data  has  been  pre¬ 
sented. 

Project  statuses  are  com¬ 
municated  on  a  weekly  basis 
to  management  during 
weekly  meetings.  Other 
management  oversight 
meetings  are  scheduled  as 
appropriate  (e.g.  milestone, 
checkpoint,  and  postmor¬ 
tem). 

See  scripts  STATUS, 

WEEK,  CHECKPOINT,  PM 
and  CYCLE. 

MA 

GG  2 

The  process  is  institutiona¬ 
lized  as  a  managed  process. 

MA  GP 

2.1 

Establish  and  maintain  an 
organizational  policy  for  plan¬ 
ning  and  performing  the  mea¬ 
surement  and  analysis 
process. 

No  policies  provided 
in  AIM 

The  organization  must  de¬ 
velop  its  policies. 

MA  GP 

2.2 

Establish  and  maintain  the 
plan  for  performing  the  mea¬ 
surement  and  analysis 
process. 

Individual  process 
scripts  sometimes 
describe  what  data 
is  collected  and  how 
it  is  analyzed  (e.g. 
the  WEEK  and  PM 
scripts  say  “review 
this”  but  not  how  to 
do  it).  In-depth  dis¬ 
cussion  of  the 
measures  and  de¬ 
rived  measures  is 
available  in  the  TSP 
Books. 

The  measurement  plan  is 
embedded  in  the  standard 
business  rhythm  of  the  AIM 
project  (e.g.  the  launch 
process  and  scripts,  the  data 
collection  associated  with 
the  workbooks,  and  the 
preparation  and  delivery  of 
the  weekly  status  and  man¬ 
agement  review  meetings). 

MA  GP 

2.3 

Provide  adequate  resources 
for  performing  the  measure¬ 
ment  and  analysis  process, 
developing  the  work  products, 
and  providing  the  services  of 
the  process. 

Launch  records 
showing  the  team 
leader  and  various 
team  role  assign¬ 
ments 

Scheduled  events  have 
resources  associated  with 
them,  such  as  the  launch, 
weekly  meetings,  and  man¬ 
agement  meetings. 

MA  GP 

2.4 

Assign  responsibility  and 
authority  for  performing  the 
process,  developing  the  work 
products,  and  providing  the 
services  of  the  measurement 
and  analysis  process. 

Team  leader  and 
role  manager  de¬ 
scriptions,  especially 
the  planning, 
process,  and  quality 
managers 

Form  RSIM  and 

SRAM 

See  Relevant  Stakeholder 
Involvement  Matrix  and  the 
Stakeholder  Role  Assign¬ 
ment  Matrix. 
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TSP/PSP 

CMMI 

CMMI  PA:  Measurement  and  Direct  Artifact 

Guidance 

Reference 

Feature 

Analysis  (MA)  Description 

MA  GP 

2.5 

Train  the  people  performing  or 
supporting  the  measurement 
and  analysis  process  as 
needed. 

PSP/TSP  training 
records 

TSP  and  AIM  training 

The  TSP  has  training  re¬ 
quirements  for  TSP  team 
members.  All  SEI-authorized 
PSP/TSP  courses  address 
the  principles  for  measure¬ 
ment  needed  for  specific 
roles  (e.g.,  leader,  member, 
developer) 

Comprehensive  SEI  training 
and  authorization  for  TSP 
coaches. 

MA  GP 

2.6 

Place  designated  work  prod¬ 
ucts  of  the  measurement  and 
analysis  process  under  ap¬ 
propriate  levels  of  control 

Stored  project  note¬ 
book  using  appropri¬ 
ate  configuration 
management  prac¬ 
tices 

The  planning  manager  is 
responsible  for  placing  all 
project  planning  artifacts  into 
the  project  notebook.  The 
content  of  the  project  note¬ 
book  is  defined  in  specifica¬ 
tion  NOTEBOOK. 

The  support  manager  is 
responsible  for  developing  a 
plan  for  the  management  of 
all  project  data  identified  in 
the  specification 

NOTEBOOK.  This  is  usually 
accomplished  by  designating 
a  specific  project  folder  on  a 
drive  or  using  a  web-based 
file-sharing  system;  levels  of 
control  are  handled  by  set¬ 
ting  access  permissions. 

MA  GP 

2.7 

Identify  and  involve  the  rele¬ 
vant  stakeholders  of  the  mea¬ 
surement  and  analysis 
process  as  planned. 

RSIM 

Launch  scripts 

PREPL  filled  out, 

LAU9  meeting  report 

RSIM  provides  a  compre¬ 
hensive  set  of  stakeholders 
and  involvement. 

MA  GP  Monitor  and  control  the  mea- 

2.8  surement  and  analysis 

process  against  the  plan  for 
performing  the  process  and 
take  appropriate  corrective 
action 

Launch  meeting 
minutes,  workbooks, 
and  launch  meeting 

9 

Weekly  meeting 
minutes 

Management  meet¬ 
ing  minutes 

M&A  is  embedded  in  the 

AIM  business  rhythm.  Col¬ 
lection  of  data  is  monitored 
closely  by  the  coach,  plan¬ 
ning  manager,  and  the  team 
leader. 

Management  monitors  M&A 
by  reviewing  project  data 
weekly/ 
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TSP/PSP 

Reference 


CMMI  CMMI  PA:  Measurement  and 

Feature  Analysis  (MA)  Description 

MA  GP  Objectively  evaluate  adhe- 

2.9  rence  of  the  measurement 

and  analysis  process  against 
its  process  description,  stan¬ 
dards,  and  procedures;  ad¬ 
dress  noncompliance. 


MA  GP 
2.10 


Review  the  activities,  status, 
and  results  of  the  measure¬ 
ment  and  analysis  process 
with  higher  level  management 
;  resolve  issues. 


MA  GG  3  The  process  is  institutiona¬ 
lized  as  a  defined  process. 


MA  GP  Establish  and  maintain  the 
3.1  description  of  a  defined  mea¬ 

surement  and  analysis 
process. 


MA  GP  Collect  work  products,  meas- 

3.2  ures,  measurement  results, 

and  improvement  information 
derived  from  planning  and 
performing  the  measurement 
and  analysis  process  to  sup¬ 
port  the  future  use  and  im¬ 
provement  of  the  organiza¬ 
tion’s  processes  and  process 
assets. 


Direct  Artifact  Guidance 


Checkpoint  report 

See  the  role  of  the 

PG  (Process  Group) 
Coaching  Manager. 
Coaching  Manager 
report 

TSP  coach  involve¬ 
ment  pre-launch 
(PREPL/PREPR 
filled  out),  during  the 
launch  (LAU  meeting 
minutes),  and  after 
(LAUPM) 

TSP  checkpoint 
results 

The  TSP  coach  will  perform 
a  Checkpoint  to  evaluate 
process  and  work  products, 
including  M&A 

During  the  launch,  the  coach 
guides  process  fidelity  for 

M&A.  As  the  project  ex¬ 
ecutes,  the  team  leader  and 
planning  and  process  man¬ 
agers  objectively  evaluate. 
When  the  Process  Group 
(PG)  is  formed  the  Coaching 
Manager  role  will  objectively 
evaluate  the  launch  process 
and  artifacts  for  each  launch. 

Actual  weekly  status 
presentations  to 
management,  meet¬ 
ing  minutes,  and 
management  reports 

The  OSSP  will  con¬ 
tain  the  standard 
processes,  which 
include  M&A / 

The  Launch  Note¬ 
book  (PREPL, 

PREPR,  LAU  1-9, 
WEEK) 

The  TSP+  role  of  Process 
Group  Support  Manager  is 
responsible  for  establishing 
and  maintaining  the  OSSP. 

The  OSSP  will  contain  the 
launch  processes,  which  are 
the  main  planning  processes 
along  with  associated  data 
collection  and  reporting. 

The  Launch  Notebook 
(PREPL,  PREPR,  LAU1-9, 
WEEK) 

Project 

NOTEBOOKS  (in¬ 
cludes  weekly 

SUMS,  SUMP, 

SUMQ,  WEEK 
project  status, 
SUMMARY  reports 
and  PM  results) 
Lessons  Learned 
and  Process  Im¬ 
provements. 

It  is  the  responsibility  of  all 
project  personnel  to  includ¬ 
ing  management  to  report 
lessons  learned  and/or 
process  improvements  as¬ 
sociated  with  MA  activities. 

This  information  shall  be 
reported  to  the  process 
group. 

All  projects  shall  report 
process  improvements  on  a 

PIP  Form.  In  particular 
projects  need  to  use  their 
postmortem  time  as  an  op¬ 
portunity  for  process  im¬ 
provement  and  lessons 
learned. 
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3.4.4  Decision  Analysis  and  Resolution  (DAR) 


The  following  table  lists  the  elements  of  the  Decision  Analysis  and  Resolution  (DAR)  process 
area  employed  in  the  AIM  approach. 


TSP/PSP 

Reference 

CMMI  Fea¬ 
ture 

CMMI  PA:  Decision 

Analysis  and  Resolution 
Description 

Direct  Artifact 

Guidance 

DAR  SG  1 

Decisions  are  based  on  an 
evaluation  of  alternatives 
using  established  criteria. 

The  TSP+  provides  an  ele¬ 
mentary  DAR  framework.  The 
essence  of  DAR  is  embedded 
in  the  TSP+  DAR  form 

The  organization  may  need  to 
develop  or  provide  additional 
guidance. 

DAR  SP 

1.1 

Establish  and  maintain 
guidelines  to  determine 
which  issues  are  subject  to 
a  formal  evaluation  process. 

The  organization  needs  to 
establish  DAR  guidelines. 

Often  the  PG  will  facilitate. 

DAR  SP 

1.2 

Establish  and  maintain  the 
criteria  for  evaluating  alter¬ 
natives  and  the  relative 
ranking  of  these  criteria. 

Form  DAR 

DAR  SP 

1.3 

Identify  alternative  solutions 
to  address  issues. 

Form  DAR 

DAR  SP 

1.4 

Select  the  evaluation  me¬ 
thods. 

Form  DAR 

DAR  SP 

1.5 

Evaluate  alternative  solu¬ 
tions  using  the  established 
criteria  and  methods. 

Form  DAR 

DAR  SP 

1.6 

Select  solutions  from  the 
alternatives  based  on  the 
evaluation  criteria. 

Form  DAR 

DAR  GG  3 

The  process  is  institutiona¬ 
lized  as  a  defined  process. 

DAR  GP 

2.1 

Establish  and  maintain  an 
organizational  policy  for 
planning  and  performing  the 
decision  analysis  and  reso¬ 
lution  process. 

See  the  Implementation  Guide 

DAR  GP 

2.2 

Establish  and  maintain  the 
plan  for  performing  the  de¬ 
cision  analysis  and  resolu¬ 
tion  process. 

See  the  instructions 
for  DAR. 

See  tasks  in  plan. 

DAR  GP 

2.3 

Provide  adequate  resources 
for  performing  the  decision 
analysis  and  resolution 
process,  developing  the 
work  products,  and  provid¬ 
ing  the  services  of  the 
process. 

TSP+  Plan 

DAR  GP 

2.4 

Assign  responsibility  and 
authority  for  performing  the 
process,  developing  the 
work  products,  and  provid¬ 
ing  the  services  of  the  deci¬ 
sion  analysis  and  resolution 
process. 

TSP+  plan  see  task 
for  DAR 
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TSP/PSP 

Reference 

CMMI  Fea¬ 
ture 

CMMI  PA:  Decision 

Analysis  and  Resolution 
Description 

Direct  Artifact 

Guidance 

DARGP 

2.5 

Train  the  people  performing 
or  supporting  the  decision 
analysis  and  resolution 
process  as  needed. 

TSP+  training 

The  PG  will  usually  develop 
and  provide  traininq  on  the 
OSSP 

DARGP 

2.6 

Place  designated  work 
products  of  the  decision 
analysis  and  resolution 
process  under  appropriate 
levels  of  control. 

LOGCI 

project  notebook 

DARGP 

2.7 

Identify  and  involve  the 
relevant  stakeholders  of  the 
decision  analysis  and  reso¬ 
lution  process  as  planned. 

RSIM 

DAR  form 

DARGP 

2.8 

Monitor  and  control  the 
decision  analysis  and  reso¬ 
lution  process  against  the 
plan  for  performing  the 
process  and  take  appropri¬ 
ate  corrective  action. 

Weekly  meeting 
minutes 

Management  meet¬ 
ings 

Status  of  DAR  Tasks 
in  Plan 

DARGP 

2.9 

Objectively  evaluate  adhe¬ 
rence  of  the  decision  analy¬ 
sis  and  resolution  process 
against  its  process  descrip¬ 
tion,  standards,  and  proce¬ 
dures;  address  noncom¬ 
pliance. 

Checkpoint 

DARGP 

2.10 

Review  the  activities,  status, 
and  results  of  the  decision 
analysis  and  resolution 
process  with  higher  level 
management ;  resolve  is¬ 
sues. 

Management  Meet¬ 
ing  Minutes  and 
presentations 

DARGP 

3.1 

Establish  and  maintain  the 
description  of  a  defined 
decision  analysis  and  reso¬ 
lution  process. 

Script  DAR 

DAR  instructions 

Form  DAR 

DARGP 

3.2 

Collect  work  products, 
measures,  measurement 
results,  and  improvement 
information  derived  from 
planning  and  performing  the 
DAR  process  to  support  the 
future  use  and  improvement 
of  the  organization’s 
processes  and  process 
assets. 

Process  Asset  Li¬ 
brary  and  Data  repo¬ 
sitory 

TSP  Checkpoint 
results,  inspection 
reports,  unit  test 
results,  issues  in  ITL 
(IRTL  in  the  TSP 

Excel  tool),  project 
management  arti¬ 
facts  reflecting  QA 
activities  and  stored 
in  the  project 
NOTEBOOK 

The  PG  role  of  Process  Asset 
and  Data  Repository  Manager 
is  responsible  for  establishing 
and  maintaining  the  organiza¬ 
tion’s  Process  Asset  Library 
and  Data  Repository. 

SOFTWARE  ENGINEERING  INSTITUTE  |  88 


References 


[Humphrey  2011] 

Humphrey,  W.  &  Over,  J.  Leadership,  Teamwork,  and  Trust:  Building  a  Competitive  Software 
Capability.  Addison- Wesley,  2011  (ISBN:  0321624505). 

[Wall  2007] 

Wall,  D.;  McHale,  J;  &  Pomeroy-Huff,  M.  Case  Study:  Accelerating  Process  Improvement  by 
Integrating  the  TSP  and  CMM/(CMU/SEI-2007-TR-013).  Software  Engineering  Institute,  Car¬ 
negie  Mellon  University,  2007.  www.sei.cmu.edu/library/abstracts/reports/07tr013.cfm 


SOFTWARE  ENGINEERING  INSTITUTE  |  89 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  in¬ 
cluding  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  information  Operations  and  Reports,  1215  J  efferson  Davis  Highway,  Suite  1204,  Arlington,  VA 
22202-4302,  and  to  the  Office  of  Managementand  Budget,  Paperwork  Reduction  Project (0704-0188),  Washington,  DC  20503. 

1.  AGENCY  USE  ONLY 

(Leave  Blank) 

2.  REPORT  DATE 

December  2010 

3.  REPORTTYPE  AND  DATES  COVERED 

Final 

4.  TITLE  AMT  SUBTITLE 

Guide  forSCAMPI  Appraisals:  Accelerated  Improvement  Method  (AIM) 

5.  FUNDING  NUMBERS 

FA8721-05-C-0003 

6.  AUTHOR(S) 

Gene  Miluk,  J  ames  M cH ale,  &  Timothy  A.  Chick 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Software  Engineering  Institute 

Carnegie  Mellon  University 

Pittsburgh,  PA  15213 

8.  PERFORMING  ORGAMZARON 

REPORT  NUMBER 

CMU/SEI-2010-SR-021 

9 .  SPONSOR!  NGlWOMTORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

HQ  ESC/XPK 

5  Eglin  Street 

Hanscom  AFB,  MA  01731-2116 

10.  SPONSORING^MOMTORING  AGENCY  REPORT 

NUMBER 

11.  SUPPLEMENTARY  NOTES 

12A  DISTRIBUTION/ AVAILABIUTY  STATEMENT 

Unclassified/Unlimited,  DTIC,  NTIS 

12b  distribution  code 

13.  ABSTRACT*  (MAXIMUM  200  WORDS) 

The  Software  Engineering  Institute's  Accelerated  Improvement  Method  (AIM)  incorporates  a  new  version  of  the 
Team  Software  Process  (TSP)  The  Team  Software  Process  Plus  (TSP).  TSP  +  is  a  project-based  implementation  of 
many  of  the  specific  and  generic  practices  of  Capability  Maturity  Model  Integration  (CMMI)  for  Development.  Organi¬ 
zations  using  AIM  for  their  improvement  approach  will  be  implementing  similar  processes  with  similar  artifacts.  Since 
these  implementations  of  CMMI  start  from  a  common  base,  the  work  of  appraising  such  organizations  againsta  spe¬ 
cific  model  scope  should  benefit  from  this  commonality  of  approach. 

This  document  therefore  provides  guidance  to  lead  appraisers  and  appraisal  teams  unfamiliar  with  TSP  +  when  con¬ 
ducting  Standard  CMMI  Appraisal  Method  for  Process  Improvement  (SCAM  PI)  appraisals  within  organizations  that 
use  the  TSP  +  as  a  foundational  operational  practice.  The  intended  benefits  of  this  guidance  are  (1)  to  shorten  the 
time  needed  to  prepare  and  conduct  such  appraisals;  (2)  to  provide  information  helpful  for  appropriate  interpretations; 
(3)  and  to  familiarize  SCAMPI  leads  and  appraisal  teams  with  a  powerful,  proven,  and  available  technology. 

14.  SUBJECT  TERMS  15.  NUMBER  OF  PAGES 

Accelerated  Improvement  Method,  AIM,  Team  Software  Process,  TSP,  97 

TSP+,  SCAMPI,  Standard  CMMI  Appraisal  Method  for  Process  Improve¬ 
ment,  process  appraisals 

16.  PRICE  CODE 


17.  SECURITY  CLASSIFICATION  OF  18.  SECURITY  CLASSIFICATION  19.  SECURITY  CLASSIFICATION  20.  LIMITATION  OF  ABSTRACT 

REPORT  OF  THIS  PAGE  OF  ABSTRACT  j  ^ 

Unclassified  Unclassified  Unclassified 


NSN  7540-01-280-5500 


Standard  Form  298  (Rev.  2-89)  Prescribed  by  ANSI  Std.  Z39-18  298-102 


